简介：seat-map.js是一款面向Web前端开发者的互动式座位图JavaScript库，基于@tixel/seat-map封装，适用于演唱会、体育赛事、剧场剧院等在线选座场景，帮助开发者少写底层渲染逻辑，快速搭建可交互的座位布局并支持异步加载场馆地图。压缩包体积仅8KB，共5个文件，核心为src目录下的seat-map.js源码，配套package.json指定依赖与入口信息，readme.md记录安装和调用方法；两张SVG场地示例可作为自定义场馆座位图的参考底图，其中一份为rod-laver场馆、另一份为sydney-myer-bowl场馆，整体目录紧凑、便于二次修改。该资源已有898人学习下载。通过源码和示例，读者可以掌握createSeatMap工厂函数的初始化流程、venues场所配置对象的使用方式，以及前后端异步取图渲染机制；结合示例SVG，还能学习如何将静态场馆图转化为可点击选座的交互界面，适合具有一定JavaScript基础的前端开发者直接引入项目或作为座位图模块的开发参考。
1. seat-map.js到底在解决什么问题：互动式座位图不是画图，是数据交互
做活动报名系统那阵子，甲方提了个需求：后台导出的座位表是Excel，用户报名后得自己对着表格找座位。这个体验多反人类，不用我说。后来换成互动式座位图，用户打开页面直接看到整个场馆的座位布局，已售、可选、锁定一眼就明白，点一下就能选中。所谓互动式座位图，本质上就是把座位数据变成一块可以点击、缩放、拖拽的可视化画布——它不解决画图问题，解决的是数据选择和状态反馈的问题。
seat-map.js这类方案适合谁？适合做售票系统、活动报名、会议室预约、甚至食堂占座这类场景的前端开发者。它不值得从零造轮子，但直接找个库也得知道原理，不然定制需求一来就翻车。这篇我把做互动式座位图的完整思路、可抄的代码和踩过的坑一起讲掉。
2. 先拆穿底层逻辑：座位图的数据模型和渲染选型
2.1 为什么不能把座位画成一堆 HTML 块
很多新手拿到「互动式座位图」的需求，第一反应是用 div 拼格子，每个座位一个 div，绑上 click 事件。这种做法在 20 个座位的会议室里没问题，到了 500 座的剧场就开始暴露问题。
问题出在哪？第一，DOM 数量。500 个座位就是 500 个节点，每个节点还挂监听器，页面的内存占用和事件分发开销直线上升。第二，缩放。用户要放大看座位号，div 方案做缩放要么用 CSS transform 硬撑，要么靠 re-render 重排，交互帧率稳不住。第三，状态同步。座位有可选、已售、选中、锁定四种状态，用 DOM class 来回切换，状态一多，逻辑就散落在各个节点上。
我一般用 Canvas 或 SVG 渲染，把座位当成图形对象而不是 DOM 节点。这么做的好处有三个：图形数量大时性能稳；缩放平移可以走 Canvas 的变换矩阵，不用碰 DOM；座位的状态变化只重绘局部区域，不用整页刷新。seat-map.js 这类库走的也是这个路子，先定义数据模型，再决定怎么画。
Canvas 和 SVG 之间，我选 Canvas。原因很直接：座位图动辄上千个图形对象，SVG 的 DOM 节点同样会爆炸。Canvas 是位图模式，画 1000 个矩形和画 100 个矩形，性能差异在帧率上几乎看不出来。代价是交互命中检测要自己算——鼠标点在哪个座位上，得靠坐标反查。
2.2 渲染层：Canvas 最小场景的初始化与坐标体系
先看一个最朴素的 Canvas 初始化逻辑。这个代码是所有后续功能的地基，坐标体系在这里定下来。
// 初始化画布，返回 Canvas 上下文和基础配置 function initCanvas(containerId, width, height) { const container = document.getElementById(containerId); const canvas = document.createElement('canvas'); canvas.width = width; canvas.height = height; canvas.style.width = width + 'px'; canvas.style.height = height + 'px'; container.appendChild(canvas); const ctx = canvas.getContext('2d'); // 这里用 devicePixelRatio 适配高清屏，不然在 Retina 屏上会发虚 const dpr = window.devicePixelRatio || 1; canvas.width = width * dpr; canvas.height = height * dpr; ctx.scale(dpr, dpr); return { canvas, ctx, width, height }; } // 渲染一个座位：矩形 + 座位号文字 function drawSeat(ctx, seat) { const { x, y, size, label, status } = seat; ctx.save(); if (status === 'available') { ctx.fillStyle = '#3b82f6'; } else if (status === 'sold') { ctx.fillStyle = '#9ca3af'; } else if (status === 'selected') { ctx.fillStyle = '#f59e0b'; } else { ctx.fillStyle = '#6b7280'; // locked } ctx.fillRect(x, y, size, size); ctx.fillStyle = '#ffffff'; ctx.font = '12px sans-serif'; ctx.textAlign = 'center'; ctx.textBaseline = 'middle'; ctx.fillText(label, x + size / 2, y + size / 2); ctx.restore(); }这里有两个关键参数要理解：devicePixelRatio和坐标原点。dpr不处理的话，同样一套坐标在高分屏上画出来是模糊的，因为 CSS 像素和物理像素不是 1:1。我习惯把画布的物理尺寸设为逻辑尺寸乘以dpr，再用ctx.scale(dpr, dpr)把坐标系拉回逻辑坐标，这样后续所有鼠标事件的坐标都不用做额外换算。
drawSeat里我把颜色和状态绑定在一起，这是最朴素的映射方式。注意ctx.save()和ctx.restore()成对出现，防止fillStyle和font的修改泄漏到下一次绘制。单看一块代码可能觉得啰嗦，但状态一多，这种隔离能省掉大量「颜色突然不对了」的排查时间。
2.3 缩放和平移：为什么说变换矩阵是互动座位图的心脏
互动式座位图区别于静态图的核心，就是用户能缩放、能拖动。这个能力如果靠改每个座位的坐标来实现，等于每次缩放都要重新计算所有座位的位置，性能上不可接受。
正确做法是维护一个viewport（视口）对象，记录缩放比例和偏移量。绘制时用 Canvas 的setTransform一次性应用，所有座位只需要按原始坐标绘制。
// viewport 结构 const viewport = { scale: 1, // 当前缩放比例，范围建议 0.5 ~ 3 offsetX: 0, // X 轴偏移量，单位是逻辑像素 offsetY: 0, // Y 轴偏移量 }; // 每次重绘前应用视口变换 function render(canvas, ctx, seats, viewport) { ctx.clearRect(0, 0, canvas.width, canvas.height); ctx.save(); ctx.setTransform(viewport.scale, 0, 0, viewport.scale, viewport.offsetX, viewport.offsetY); seats.forEach(seat => drawSeat(ctx, seat)); ctx.restore(); } // 缩放：围绕鼠标位置缩放 function zoomAt(mouseX, mouseY, deltaScale) { const newScale = Math.min(3, Math.max(0.5, viewport.scale * deltaScale)); // 缩放比例变化后，要让鼠标指向的座位不动，需要补偿偏移量 const ratio = newScale / viewport.scale; viewport.offsetX = mouseX - (mouseX - viewport.offsetX) * ratio; viewport.offsetY = mouseY - (mouseY - viewport.offsetY) * ratio; viewport.scale = newScale; render(canvas, ctx, seats, viewport); }zoomAt里的补偿公式是重点。如果只改scale，缩放后的画面会以画布原点为中心缩放，鼠标所在位置的座位会跑掉，用户体验很差。补偿逻辑让鼠标下的那个点在缩放前后保持屏幕位置不变——这是所有地图类组件的基础算法。
注意我限制了缩放范围0.5 ~ 3，这是从实际使用里总结的参数：小于 0.5，座位密集时点不准；大于 3，座位被放大到屏幕外，拖动找回的成本太高。这两个边界值可以按你的场馆规模调整，但原理不变——没有边界的缩放就是失控的缩放。
3. 跑通最小闭环：用 seat-map.js 从一张二维数组到可点选座位
3.1 数据准备：把座位表抽象成结构化的二维数组
做互动式座位图的第一个步骤不是写代码，而是定数据格式。我踩过最深的坑就是一上来就画界面，画到一半发现数据里没有座位状态字段，又回去改接口。
常见做法是定义一个扁平化的座位对象数组，每个座位包含区域、行列、状态、标签四个核心信息。排期座位图不适合用嵌套结构，因为你不知道每个区域的座位是不是规则的矩形。有些剧场有弧形排布、有缺口，嵌套数组会把人逼疯。
// 座位数据模型 // x, y 是座位左上角在画布上的逻辑坐标，size 是边长 // status 取值：available（可选）、sold（已售）、selected（选中）、locked（锁定） const seats = [ { id: 'A-01', x: 40, y: 40, size: 28, label: 'A1', status: 'available' }, { id: 'A-02', x: 80, y: 40, size: 28, label: 'A2', status: 'sold' }, { id: 'A-03', x: 120, y: 40, size: 28, label: 'A3', status: 'available' }, // 后续数据可以来自后端接口，也可以前端根据行列号自动生成 ]; // 从后端接口拿数据的常见形态 const response = await fetch('/api/venue/seat-map'); const seatMapData = await response.json(); // 接口返回的通常是 { rows: 8, cols: 12, soldSeats: ['A2','B5'], lockedSeats: ['C1'] } // 前端拿到后需要展开为上面的扁平数组如果你没有后端，前端也可以用两层循环生成座位。rows和cols决定座位数量，soldSeats和lockedSeats是排除项。展开逻辑我一般放在独立函数里，方便测试。注意座位 ID 必须全局唯一，因为后面做状态更新、提交订单、和后端对账都靠它。用A-01这种带区域前缀的字符串做 ID，比纯数字更直观，排查问题时一眼能看出座位位置。
3.2 事件命中检测：从鼠标坐标到座位对象的数学映射
Canvas 的问题在于它是个整体，浏览器不知道你画了什么。鼠标点了坐标(x, y)，你要自己算出它落在哪个座位里。
命中检测有朴素写法和优化写法。座位数量低于 500 个时，遍历是没问题的，每个座位做一个矩形包含判断，开销极小。超过 1000 个时才需要考虑空间索引，比如把画布分块，先定位鼠标落在哪个块，再查块里的座位。我一开始图省事直接全局遍历，结果一场 2000 座的演唱会图在低端手机上点一下要卡 100 毫秒，后来加了分块索引才好。
// 命中检测：把鼠标屏幕坐标转换为画布逻辑坐标，再遍历座位 function hitTest(mouseX, mouseY, seats, viewport) { // 关键：屏幕坐标转逻辑坐标 const logicalX = (mouseX - viewport.offsetX) / viewport.scale; const logicalY = (mouseY - viewport.offsetY) / viewport.scale; // 从后往前遍历，后绘制的座位优先命中，模拟视觉层级 for (let i = seats.length - 1; i >= 0; i--) { const seat = seats[i]; if ( logicalX >= seat.x && logicalX <= seat.x + seat.size && logicalY >= seat.y && logicalY <= seat.y + seat.size ) { return seat; } } return null; }这里最容易翻车的地方是坐标转换。鼠标事件给的clientX和clientY是浏览器窗口坐标，必须先减去画布在页面上的偏移量，再减去视口的offsetX/offsetY，最后除以scale，才能得到座位在原始坐标系里的坐标。我见过不少人漏掉offset或者忘记除以scale，结果放大之后点击位置完全对不上。
从后往前遍历是个小技巧。Canvas 是按顺序绘制的，后画的座位会覆盖先画的，所以视觉上最顶层的座位应该优先命中。这个细节在座位重叠时能避免「明明看见座位 A 在 B 上面，点 B 却选中了 A」的诡异问题。
3.3 把点击变成状态变更：重绘的最小粒度
命中检测拿到座位对象后，下一步就是改状态、重绘。这一步的粒度决定性能。
最差的做法是拿到一个座位后，把整块画布清空，重新遍历所有座位画一遍。座位量小感觉不到，量一大就卡。我一般维护一个dirtySet，只重绘状态变化的座位。Canvas 重绘的最小单位是矩形区域，调用ctx.clearRect和ctx.fillRect只刷新变化区域。
// 座位状态切换：带上状态机校验 function toggleSeat(seat) { // 已售和锁定的座位不能选，这是业务规则 if (seat.status === 'sold' || seat.status === 'locked') { return false; } seat.status = seat.status === 'selected' ? 'available' : 'selected'; return true; } // 局部重绘：只画变化的座位 function redrawSeat(ctx, seat) { // 先清掉这个座位的旧图形，范围稍微扩大避免边缘残留 ctx.clearRect(seat.x - 1, seat.y - 1, seat.size + 2, seat.size + 2); drawSeat(ctx, seat); }局部重绘的代价是要精确知道每个座位的绘制范围。如果座位的绘制不只是矩形，还带阴影、圆角、选中高亮边框，清理区域就得把阴影的扩散范围也算进去。我遇到过一次圆角矩形加了 4px 阴影，局部清除没算上阴影，结果重绘后座位周围残留一圈黑边，花了半小时才发现是清理范围不够。
这个最小闭环跑通后，你已经有了一个可点击、可缩放的座位图。接下来要处理的是更现实的业务逻辑：状态怎么流转、选择上限怎么控制、拖动和点击怎么区分。
4. 从点击到下单：状态机与事件链的完整设计
4.1 座位状态机的四个节点与合法流转路径
互动式座位图的业务复杂度，九成藏在座位状态里。状态不只是用来涂颜色的，它直接决定用户能不能点、点了之后后端认不认。
我常用的状态机有四态：available、selected、sold、locked。流转规则如下：available可以变成selected（用户点击选中）；selected可以回到available（用户取消）；sold和locked是终态，只能由后端接口变更，前端代码不允许碰。
这四条规则写在哪？我见过不少项目把判断散落在点击事件里，if (seat.status !== 'sold')写得到处都是，后面加一个状态就全局搜索替换。更稳的做法是集中成一个状态机函数，所有入口统一走它。
// 集中式状态机：所有状态变更都走这里 const seatStateMachine = { transitions: { available: ['selected'], selected: ['available'], sold: [], locked: [], }, canTransition(from, to) { return this.transitions[from]?.includes(to) ?? false; }, transition(seat, to) { if (!this.canTransition(seat.status, to)) { console.warn(`Illegal transition: ${seat.status} -> ${to}, seat ${seat.id}`); return false; } seat.status = to; return true; }, };集中管理的收益在项目后期特别明显。比如产品经理说「已售座位在开演前 24 小时可以释放为可选」，你只需要往transitions里加一条规则，再补一个时间和后端确认的逻辑。如果状态判断散落各处，这种需求改动会让你改到怀疑人生。
注意transitions里sold和locked的数组是空的，意味着这两个状态是终态，任何前端操作都不能改。这是安全边界——防止用户通过浏览器 DevTools 改内存里的状态把已售座位选走。真要改，必须走服务端接口。
4.2 事件链设计：click 到订单确认的四个环节
互动式座位图的事件链路比普通表单长得多：用户点座位 → 座位选中 → 已选列表更新 → 订单金额变化 → 提交订单。任何一个环节断了，用户都会觉得「点了没反应」。
完整的事件链我一般拆成四层：
第一层是原始交互事件，也就是 Canvas 的 mouse/touch 事件，负责把屏幕坐标换算成座位对象。第二层是业务状态变更，调用状态机，修改座位状态。第三层是界面同步，更新座位图右侧的已选列表、总额、剩余可选数等辅助 UI。第四层是数据上报，把变更后的座位 ID 列表同步给订单模块，等用户点击确认下单时直接提交。
// 事件链：canvas 点击 -> 座位状态变更 -> UI 同步 -> 订单数据更新 canvas.addEventListener('click', (e) => { // 第一层：坐标换算 const rect = canvas.getBoundingClientRect(); const mouseX = e.clientX - rect.left; const mouseY = e.clientY - rect.top; const seat = hitTest(mouseX, mouseY, seats, viewport); if (!seat) return; // 第二层：状态机变更 const nextStatus = seat.status === 'selected' ? 'available' : 'selected'; const ok = seatStateMachine.transition(seat, nextStatus); if (!ok) return; // 第三层：UI 同步 redrawSeat(ctx, seat); updateSelectedList(seats); // 刷新右侧已选列表 updateOrderSummary(seats); // 刷新金额和数量 // 第四层：同步订单模块 orderModule.setSelectedSeats( seats.filter(s => s.status === 'selected').map(s => s.id) ); });这里有个容易被忽略的细节：click事件在移动端有 300ms 延迟。如果你直接监听click，手机上点座位会有明显延迟感。我在移动端改用pointerdown+pointerup组合判断，同时用 10ms 的位移阈值区分「点击」和「拖动」——位移超过 5px 就当作拖动场景，不再触发点击逻辑。
4.3 多选与上限控制：选座体验的最后一块拼图
活动选座通常不是单选，用户要连着选几个朋友的位置。多选逻辑本身简单，麻烦的是「连坐」约束——很多场馆允许用户一次选多个座位，但要求这几个座位必须相邻。
连坐校验的实现思路是按区域分组做邻居检测。选中一个新座位后，检查它在已选座位集合里的邻接关系：新座位至少要与一个已选座位在行号相同且列号相邻。
// 连坐校验：新选中的座位必须与已有座位相邻 function isAdjacent(newSeat, selectedSeats) { return selectedSeats.some((s) => { const sameRow = s.row === newSeat.row; const colDiff = Math.abs(s.col - newSeat.col); const sameCol = s.col === newSeat.col; const rowDiff = Math.abs(s.row - newSeat.row); // 同行相邻或者同列相邻都算，具体看场馆排布 return (sameRow && colDiff === 1) || (sameCol && rowDiff === 1); }); }注意这个校验的前提是座位数据里有row和col字段。如果只有x和y坐标，你需要从坐标反推行列号。我一般在展开后端数据时就补上row和col，因为坐标算邻接关系在弧形排布的场馆里完全不靠谱——两个座位在屏幕上距离很近，实际却隔了一条过道。
选座上限也是一个硬需求。电影票通常限 6 张，剧院演出可能限 4 张。这个限制最好在状态机外面控制，因为它不是座位状态的问题，是订单维度的问题。我在订单模块里维护一个maxSeatsPerOrder常量，每次用户点选新座位前检查已选数量 + 1是否超限，超限直接拦截并弹出轻提示。
5. 避坑指南：互动式座位图最常见的 5 次翻车现场
5.1 缩放后点击座位坐标全偏了
现象：座位图能正常缩放，但放大之后点击座位，选中的总不是鼠标指向的那个。缩小之后又恢复正常。
原因：命中检测时没有把屏幕坐标转换回逻辑坐标。我最初写hitTest时直接拿clientX - rect.left去和座位的x比较，没乘viewport.offsetX和viewport.scale。座位图缩小到 0.5 倍时，点击偏差刚好是鼠标位置的一半，肉眼很难立刻发现规律。
解决：在命中检测函数的第一行，强制做一次坐标转换。为了以后不再犯，我在代码里加了注释，标明logicalX和logicalY的来源公式，以及两个常用变量名offsetX的含义。这也提醒所有后续接手代码的人——坐标转换不能省略，它是整个命中检测的基石。
5.2 拖动画布时误触发了座位选中
现象：用户拖动座位图想查看后排区域，松手时突然弹出了「座位已选中」的提示。体验非常差。
原因：我把点击和拖动都挂在click事件上，浏览器认为松手就是click。用户从按下到松开之间移动了上百像素，这个动作也被当成了点击。
解决：区分手势，用按下和松开的坐标差作为判断阈值。按下时记录startX/startY，松开时计算位移，超过 5px 就判定为拖动，不触发座位选中逻辑。监听事件从click换成pointerdown和pointerup，同时处理鼠标和触摸，代码量多了一点，但交互体验的收益值这个成本。
let startX = 0, startY = 0, isDragging = false; canvas.addEventListener('pointerdown', (e) => { startX = e.clientX; startY = e.clientY; isDragging = false; }); canvas.addEventListener('pointermove', (e) => { const dx = e.clientX - startX; const dy = e.clientY - startY; if (Math.hypot(dx, dy) > 5) isDragging = true; }); canvas.addEventListener('pointerup', (e) => { if (isDragging) return; // 这里才执行座位选中逻辑 handleSeatClick(e); });5.3 移动端双击放大把页面也跟着放大
现象：在手机上打开座位图，双击想放大，结果页面整体缩放，字体全变大了，座位图没放大。
原因：浏览器的默认行为把双击解释为页面缩放。Canvas 自己实现的缩放逻辑发生在 JS 层，但浏览器的原生手势优先级更高。
解决：在 Canvas 上注册gesturestart和doubleclick事件的preventDefault，并在 CSS 里加touch-action: manipulation。touch-action很关键，它告诉浏览器这个元素的手势由 JS 处理，不要干预。注意不是touch-action: none，那样会连滚动都禁掉，页面其他部分的纵向滚动也会失灵。
5.4 2000 个座位同时渲染，低端机直接白屏
现象：数据量一上来，整页卡顿到无法操作，部分低端 Android 机型直接白屏。
原因：每次重绘全量遍历座位，drawSeat里还做了ctx.save()、ctx.restore()和字体设置，这些操作在 Canvas 里都是开销。2000 个座位 × 多次绘制函数调用，叠加起来就是一场性能灾难。
解决：两层优化。第一层是渲染隔离，把静态背景（已售和锁定的座位）画在一个离屏 Canvas 上，缩放时只放大离屏 Canvas，不需要重画。第二层是按需重绘，选中的座位状态变化只调redrawSeat局部重画，不碰其他座位。
// 离屏 Canvas：把静态座位一次性画好 const offscreen = document.createElement('canvas'); offscreen.width = venueWidth; offscreen.height = venueHeight; // 把 sold 和 locked 座位画到离屏上 seats.filter(s => s.status === 'sold' || s.status === 'locked') .forEach(s => drawSeat(offscreen.getContext('2d'), s)); // 主画布渲染时直接把离屏 Canvas 当作背景贴上去 function renderWithOffscreen(ctx, offscreen, interactiveSeats, viewport) { ctx.save(); ctx.setTransform(viewport.scale, 0, 0, viewport.scale, viewport.offsetX, viewport.offsetY); ctx.drawImage(offscreen, 0, 0); interactiveSeats.forEach(s => drawSeat(ctx, s)); ctx.restore(); }5.5 切换页面再返回，已选座位丢失
现象：用户选好了座位，切到别的页面查了一下信息，再返回座位图，之前选中的座位全部变回可选状态。
原因：页面切换（比如 SPA 里的路由跳转）导致组件销毁，内存中的座位状态被清掉了。状态没有持久化，任何意外刷新都会丢。
解决：把已选座位 ID 列表同步写入sessionStorage，键名用订单号或活动 ID 做区分。返回页面时先从sessionStorage读取，恢复座位的selected状态。注意这个方案只防刷新和页面切换，不防多端同步——如果需要跨设备同步，必须走后端接口保存草稿状态。
// 保存已选状态 function persistSelection(orderId, selectedIds) { sessionStorage.setItem(`seat-selection-${orderId}`, JSON.stringify(selectedIds)); } // 恢复已选状态 function restoreSelection(orderId, seats) { const raw = sessionStorage.getItem(`seat-selection-${orderId}`); if (!raw) return; const selectedIds = JSON.parse(raw); seats.forEach(s => { if (selectedIds.includes(s.id) && s.status === 'available') { s.status = 'selected'; } }); }这五条踩坑记录，前三条是交互层面的，不解决用户就骂「这系统真难用」；后两条是性能和可靠性层面的，不解决用户就放弃使用。每次有新项目接入座位图，我都会把这份清单发给后端和产品，让他们知道有哪些边界情况需要提前设计。
6. 进阶玩法：把座位图组件化，一套代码支撑多个场馆
6.1 抽离数据接入层：告别改一处跑全场的日子
互动式座位图的终极形态，是做成一个与业务解耦的组件，不同场馆、不同活动类型都能复用。我踩过最大的坑是座位渲染逻辑和订单逻辑耦合在一起，一个场馆要求显示会员价，另一个场馆要求区分包厢，结果都去改核心渲染代码，最后代码里塞满了if (venueType === 'theater')这种判断。
组件化的核心是定义好接口协议。我把交互式座位图的所有对外能力收敛成三组接口：数据输入（座位数据 + 排期数据）、行为配置（是否可多选、是否可缩放、状态颜色映射）、事件输出（选座变更回调、渲染完成回调）。
// seat-map 组件的使用方式 const seatMap = new SeatMap({ container: '#seat-map-container', venueId: 'venue-a-101', seats: seatData, options: { maxSelectable: 6, allowZoom: true, allowPan: true, adjacentOnly: true, // 是否强制连坐 statusColors: { available: '#3b82f6', sold: '#9ca3af', selected: '#f59e0b', locked: '#6b7280', }, }, onSelectionChange: (selectedIds) => { // 产线好自己的通知逻辑 updateOrderSummary(selectedIds); }, });这个接口设计的好处是，业务方只需要提供数据和回调，不需要关心 Canvas 怎么画、命中检测怎么做。我见过团队把座位图直接封装成一个 Web Component，四个场馆四套后台系统共用同一份代码，新增场馆只加数据，渲染层一行没改。
6.2 验证清单：交付前跑一遍这些用例再上线
互动式座位图上线前，我习惯按下面这份清单逐项过，任何一项不过都不允许发布。这份清单来自一次线上事故的教训——那次的 bug 是「座位选择状态正确，但提交订单时传给后端的座位 ID 顺序全乱了」，排查了三个小时发现是filter的返回顺序和渲染顺序不一致。
第一项：缩放边界测试。连续缩放 20 次，确认缩放到最小或最大时画面不会越界，偏移量不会变成NaN。第二项：坐标偏差测试。在 0.5 倍、1 倍、2 倍三个缩放级别下分别点击座位，确认命中的座位和视觉一致。第三项：状态流转测试。用脚本模拟点击 100 次，确认没有非法状态转换，已售和锁定座位始终无法被选中。第四项：数据往返测试。选择 5 个座位，刷新页面，确认从sessionStorage恢复的状态正确。
第五项我要重点说：并发与顺序测试。模拟多个用户同时抢同一个座位，后端只接受第一个请求，第二个请求要拿到明确的「座位已被占用」错误并更新座位图。这种场景千万别在前端做乐观锁之外的第二层假设，前端显示可选不等于后端一定给你。
做完整套验证，我会再加一个压力测试：把座位数量调到 5000 个，连续拖动画布 30 秒，观察帧率能不能稳住 30fps 以上。达不到就回头看离屏 Canvas 有没有用到位、命中检测有没有走分块索引。这套流程走下来，基本没有上线后才发现「这个座位图怎么这么卡」的尴尬。
互动事务的项目做多了就会发现，座位图这类组件的难点从来不是画图，而是数据一致性、手势边界、状态流转这些看不见的细节。把这些细节沉淀成组件和清单，比重复造轮子有意义得多。希望这些经验能帮你把第一个互动式座位图做得更顺。
本文还有配套的精品资源，点击获取
