简介seat-map.js 是一款轻量级的互动式座位图 JS 组件适合前端开发者在票务选座、活动报名、场馆预约等场景中使用能快速完成座位图渲染与选座交互。它通过 npm 安装调用 createSeatMap 函数并传入目标节点与场馆标识即可加载座位图venues 对象提供现成的场所配置接口设计简洁便于二次开发与功能扩展。整个压缩包仅 8KB共 5 个文件1 个核心 JS 文件封装座位绘制与交互逻辑2 个 SVG 示例座位图展示真实场馆布局另有 1 个 package.json 依赖配置与 1 份 Markdown 说明文档目录结构清晰几乎无学习成本。该组件上线后已有 898 人学习浏览代码量小、无复杂依赖特别适合希望快速集成座位可视化与选择交互、并参考现成实现细节的前端开发者。对于需要轻量级选座方案或想了解座位图实现原理的读者这是一份非常直观的参考资料。1. seat-map.js是什么把「选座」从静态图变成可交互组件做过活动报名或票务系统的人应该都遇到过这种需求把一张座位图放到页面上用户能看见哪些座位被占了、哪些还能选点一下座位就把位置定下来。静态图片做不到这点普通HTML区块堆出来的座位图又扛不住拖拽缩放和实时状态刷新。seat-map.js 这类交互式座位图组件解决的正是这件事——它把「座位」抽象成有坐标、有状态、可点击的数据对象再通过 Canvas 或 SVG 把数据渲染成用户能直接操作的图形界面。真正动手做会发现渲染一张静态座位图非常简单难的是三件事座位数据怎么建模才不跟业务打架、鼠标点击怎么精确对应到某个座位、座位状态在多人同时操作时怎么保持一致。这篇文章按我实际做影院选座和会议报名的经验把从数据建模到Canvas渲染、从参数调优到线上踩坑的完整路径讲一遍。适合正在做票务系统、活动报名、会议室预约或考场排座的开发者也适合想把座位图嵌进小程序或后台管理系统的前端工程师。2. 坐下之前先建模座位数据结构和区域行座位的组织方式2.1 用二维数组还是座位对象数组两种建模方式的取舍第一次做座位图的人最容易上来就写const seats [[], []]用行列二维数组表示每个座位。这种方案在规则排列的影厅里确实简单seats[row][col]天然对应画布上的坐标位置遍历也直观。但规则排列只是理想情况现实中的座位图总有缺失、过道、残疾人位或者被柱子挡住的区域二维数组一旦遇到不规则形状空位怎么表示就成了问题常见的做法是塞 null 或者 undefined判断逻辑就会变得很啰嗦。我一般用座位对象数组每个座位一个扁平对象字段放在一起。这样不管是规则厅还是异形厅数据模型是统一的代码里不用到处判断「这一格是不是空位」状态更新也只需要按 seatId 精确修改不会牵连到无关座位。// 推荐座位对象数组 const seatList [ { id: A-01-01, sectionId: vip, row: A, col: 1, label: A1, status: available, price: 128 }, { id: A-01-02, sectionId: vip, row: A, col: 2, label: A2, status: sold, price: 128 }, { id: B-03-08, sectionId: normal, row: B, col: 8, label: B8, status: available, price: 88 } ];这里每个座位的id由区块、行、列拼接而成全局唯一。row和col不是画布坐标而是逻辑位置真正画的时候再通过行距、座距换算成像素坐标。这样做的收益是数据层和渲染层彻底分离后端传过来的座位数据不需要预处理前端渲染区域变化也不需要改数据。二维数组那种写法适合一次性展示不适合做要频繁更新状态的交互组件。2.2 一张座位图最少需要哪几个字段seatId、label、status、price实际业务里座位字段会越加越多但本数据模型我建议保持在四个核心字段加一个扩展字段不要一开始就把系统设计得太满。seatId 是主键所有选中、锁定、回滚操作都靠它定位座位。label 是展示给用户看的座位名比如 A1、B12它会画在座位图形内部或旁边和 id 不一定是同一个东西。status 决定座位画成什么颜色、能不能点基础值有 available、sold、selected、pending 四种后面在避坑章节会细说 pending 的用途。price 不一定每个业务都有但座位图最常见的增值功能就是不同区域不同价格提前加上能省掉后续改数据结构的麻宰。扩展字段里最常用的是disabled或locked表示座位物理上不存在或不可售。这个和 sold 不同sold 是已经被别人买了说明业务上「售罄」disabled 是位置上没有座位或者通道口纯展示不能点。很多翻车现场就是因为没区分这两个状态导致用户能看到一个「已售」的座位但实际那个位置是过道。组织的经验是数据模型里把这四个基础字段定清楚后面至少能少改一半 bug。2.3 区域(section)和分组怎么加进数据模型从影院厅到体育场的扩展单个影厅的座位图可以没有区域但会议室、体育场、音乐节这类场景必须有区域划分。区域不是给座位加一个字段就完事它要承担两种职责一是视觉上分区渲染比如 VIP 区用金色底、普通区用蓝色底二是业务上批量操作比如某个区域整片锁定、某个区域单独调价。我的做法是把区域抽成独立数组座位通过sectionId引用区域对象。const sections [ { id: vip, name: VIP区, color: #c9a86a, price: 128, rows: [A, B, C] }, { id: normal, name: 普通区, color: #5b8def, price: 88, rows: [D, E, F, G] } ];有了区域对象座位的sectionId就同时决定了它的颜色、默认价格和所属行集合。渲染时遍历座位先通过sectionId找到区域对象再取颜色和价格。区域列表也天然支持「按区域筛选座位」或「区域悬停高亮」的交互这部分第六节会给出联动实现。数据从二维数组升级到「区域 座位」两级结构是座位图从静态展示走向真实业务的必经一步几乎所有商用座位图都是这个结构。3. 用Canvas快速画出一张可交互座位图核心实现步骤3.1 画布初始化与座位的几何排布行距、座距、蛇形排列选 Canvas 还是 SVG 的决定放到第五节讲这里先用 Canvas 跑通一个最小版本。初始化时有一个容易忽略的点canvas元素上的width和height是像素值CSS 里的宽高是显示尺寸两者不一致会导致绘图模糊。标准做法是先把 devicePixelRatioDPR考虑进去在逻辑坐标下工作最后一次性缩放到物理像素。// 初始化画布处理高清屏与逻辑坐标 function initCanvas(canvas, cssWidth, cssHeight) { const dpr window.devicePixelRatio || 1; canvas.style.width cssWidth px; canvas.style.height cssHeight px; canvas.width Math.round(cssWidth * dpr); canvas.height Math.round(cssHeight * dpr); const ctx canvas.getContext(2d); ctx.scale(dpr, dpr); return ctx; }这个函数的逻辑是CSS 尺寸决定布局占位物理像素尺寸决定渲染精度ctx.scale(dpr, dpr)之后所有绘图命令都按 CSS 像素坐标来写。坐标统一了后面命中检测时鼠标坐标才能和座位坐标对齐。我不建议在渲染逻辑里到处乘 DPR那样坐标换算容易乱初始化时一次性解决最省事。座位的几何排布用一个layoutSeats函数完成给定座位数据和行距座距参数计算每个座位中心点的画布坐标。重点说一下蛇形排列奇数行从左到右偶数行从右到左这种布局能减少同排相邻座位的间距视觉上更紧凑观众找座位也更直观。实现时只需在偶数行做一个镜像换算。// 根据逻辑行列计算座位坐标支持蛇形排列 function layoutSeats(seatList, opts) { const { seatSize, gapX, gapY, rowSpacing, reverseEvenRow } opts; const seated new Map(); for (const seat of seatList) { const rowIndex seat.rowIndex; const colIndex seat.col; const reverse reverseEvenRow (rowIndex % 2 0); const effectiveCol reverse ? (seat.maxCol - seat.col 1) : seat.col; const x opts.originX effectiveCol * (seatSize gapX); const y opts.originY rowIndex * (seatSize gapY rowSpacing); seated.set(seat.id, { x, y, seat }); } return seated; }参数说明seatSize是座位直径或边长小屏手机会用 8px 左右大屏展示可以放到 14pxgapX控制同一排座位之间的空隙一般 2 到 4px太小连在一起、太大浪费空间rowSpacing是额外加的排间距视觉留白过道等场景会加大。实际项目中这些参数都做成可配置项放进组件初始化的 options 里后面第四节的「必调参数」会给出推荐取值范围。这个函数的返回值是seatId - 坐标的 Map渲染和命中检测都用它。3.2 命中检测从鼠标坐标到「点到哪个座位」的三层计算交互式座位图的灵魂是命中检测说白了一个问题鼠标点下去的那一刻坐标落在哪个座位上最笨的办法是遍历所有座位用「点和矩形/圆是否相交」逐个判定。座位数在 500 以下时这种暴力遍历没问题但到了 2000 座开始有卡顿感需要加一层快速过滤。我的实现分三步第一步把鼠标的clientX/clientY换算成 Canvas 画布内的逻辑坐标第二步按行快速过滤只保留和鼠标 y 坐标相近的行第三步在这些候选座位里做精确的圆形命中。// 鼠标事件 - 命中座位 id function hitTest(event, layout, seatSize, radius seatSize * 0.5) { // 第一步坐标换算考虑画布缩放和滚动条 const rect event.target.getBoundingClientRect(); const scaleX event.target.width / rect.width; const scaleY event.target.height / rect.height; const mx (event.clientX - rect.left) * scaleX; const my (event.clientY - rect.top) * scaleY; // 第二步粗过滤——按行找候选 for (const { x, y, seat } of layout.values()) { const dx mx - x; const dy my - y; // 第三步精确判定——圆形座位用距离矩形座位用包含 if (dx * dx dy * dy radius * radius) { return seat; } } return null; }这个函数返回命中的座位对象没有命中则返回 null。第一层换算大家容易漏的是scaleX当 canvas 的物理像素宽和 CSS 显示宽不一致时直接拿clientX - rect.left当画布坐标是错位的必须乘上宽高比例。第二层和第三层在代码里合在一起写了实际数据量大时应当把「按行粗筛」做成独立的 Map 索引把同一行的座位放一个桶里命中检测时先在桶之间做 y 坐标比较再进桶内做圆形判定。3.3 渲染与交互状态分离hover、selected、sold 三种状态的切换逻辑很多初学者把渲染和交互写在同一个函数里鼠标一移动就清空画布全量重绘。这么做功能没错但性能很差而且状态管理容易变成一团乱麻。我习惯把「状态数据」和「绘制函数」分开座位数组是唯一数据源每次状态更新只改数组对应项然后只重绘受影响的几个座位而不是整张图。// 座位状态切换只更新数据重绘交给 renderSeat function setSeatStatus(seatList, seatId, newStatus) { const idx seatList.findIndex(s s.id seatId); if (idx ! -1) { seatList[idx].status newStatus; return true; } return false; }对应的绘制函数renderSeat(ctx, seat, x, y, seatSize)根据seat.status决定颜色和样式available 是浅色底、深色描边hover 是亮色底加粗描边selected 是主色调实心sold 是灰色底加斜线pending 是半透明主色并显示加载动画。状态切换不能直接在绘制函数里处理点击应该由事件层判断当前状态是否允许切换再调用setSeatStatus更新数据最后触发局部重绘。这套分离的好处后面第四、五节会体现出来想要加缩放、加拖拽、加区域联动只要在渲染参数上做文章不需要改状态管理逻辑。用 Canvas 画座位图做到这一步已经可以应付大多数中型活动报名场景了。4. 技术选型和六个必调参数从静态展示到真实票务4.1 Canvas vs SVG vs DOM不同座位规模下的选型边界网上讨论座位图选型时容易陷入「某某技术一定更好」的争论实际工程里这是个线性问题座位数量决定技术选型。我做过对比给出一个比较实在的经验边界。方案适用规模优势劣势DOM CSS Grid200 座以内开发快、样式容易调、自带事件座位多时 DOM 节点爆炸SVG200 - 2000 座矢量缩放不糊、内置事件、可局部更新图形数量上千后事件绑定开销大Canvas2000 座以上或需复杂动画渲染性能最好、适合频繁重绘命中检测和局部重绘全要手写三种方案都有人在生产环境用关键看你的增速点在哪儿。如果只是几十个座位的会议室预约完全没必要上 CanvasDOM 加 CSS Grid 几小时就能交付。如果要做千人剧场的在线选座DOM 方案会在滚动和缩放时明显掉帧Canvas 反而是最省心的。我的推荐是不确定规模时先按 1000 座以上进行设计因为座位图一旦上线通常只会往更多座位演进很少往回缩。4.2 六个必调参数seatSize、gapX、gapY、rowSpacing、zoomRange、maxSelect不管底层用哪种方案渲染座位图组件最终都要暴露一组合适的配置项。下面这六个参数是我在多个项目里沉淀出来的直接决定一张座位图的观感和操作容错率。参数推荐范围作用与踩坑提醒seatSize8 - 14 px小于 8px 时座位看起来像噪点点击命中区域也变小gapX2 - 4 px同排座位间距过大导致一排看起来是断开的gapY2 - 4 px行内垂直间距在矩形座位下和 gapX 表现类似rowSpacing与 seatSize 的 0.8 - 1.2 倍行距纯粹靠 gapY 拉不开必须额外加 rowSpacingzoomRangemin 0.5 - 1max 3 - 4缩放范围太大会让用户迷失位置需要配合区域名渲染maxSelect1 或 3 - 5影单座选 1活动报名可能允许连坐选多个rowSpacing是新人最容易漏的参数。如果只用gapY控制行距会造成同排座位垂直间距和排间间距相同视觉上分不清「排」的边界。一般做法是排间距 seatSize gapY rowSpacing把rowSpacing单独留出来作为视觉分组空间。maxSelect则直接和业务逻辑挂钩——它控制用户最多能选几个座位超过限制后新的点击要么被忽略要么顶掉最早选中的这个交互策略要提前定义好。4.3 从静态数据到真实票务接后端接口时的数据同步模式座位图接后端接口时最常见的坑是前后端状态不一致前端显示座位可点用户刚点击就被后端拒绝因为座位已被别人锁定。最常见的做法是用「pending 状态 服务端确认」的模式用户点击可用座位后先把座位前端置为 pending发送请求给后端等后端返回成功才置为 selected失败则回滚为 available。// 选座请求乐观更新 服务端确认 失败回滚 async function selectSeat(seatId) { setSeatStatus(seatList, seatId, pending); renderDirty(); // 局部重绘 try { const res await api.reserveSeat({ seatId }); if (res.ok) { setSeatStatus(seatList, seatId, selected); } else { setSeatStatus(seatList, seatId, available); toast(res.message || 该座位已被选走); } } catch (e) { setSeatStatus(seatList, seatId, available); } renderDirty(); }这个模式的要点是把「前端乐观展示」和「服务端权威数据」区分开。pending 状态在视觉上是半透明的配合 loading 动画告诉用户正在确认避免用户连续点击同一个座位。还有个细节是请求返回后要对比返回值里的座位状态和当前前端状态如果用户在等待期间已经取消了选座就以取消后的状态为准不能无条件把返回结果写进去。线上环境还应该加一个防抖同一座位在两秒内的重复点击只发一次请求。5. seat-map.js 避坑指南五个最容易翻车的实战问题5.1 座位间距算错导致点击错位一直强调「以座位中心为准」的原因现象座位明明画在 A 位置鼠标点到座位边缘时命中失败点座位左上角却选到了上一个座位。原因非常一致绘制座位时用的是左上角坐标加宽高算出来的矩形区域但命中检测时使用的却是另一个坐标基准两者不一致。解决把「座位在画布中的位置」统一为「中心点坐标」。绘制圆角矩形时用ctx.arc(x, y, radius)命中检测也围绕(x, y)和 radius 做距离判定。如果你的座位是带圆角的矩形命中检测就用矩形包含算法判断条件是mx x - halfSize mx x halfSize这种。关键是绘制和命中必须共享同一个 layout Map不能一处写中心、一处写左上。5.2 高分辨率屏上座位糊成一团DPR 不处理后期返工现象在 2K 或 MacBook 上打开座位图座位边缘发虚文字标注像蒙了一层纱。原因大家其实都知道就是初始化时没有处理devicePixelRatiocanvas 物理分辨率远小于显示分辨率浏览器拉伸导致模糊。这个坑的隐蔽之处在于开发机如果是普通 96dpi 屏幕根本看不出来。解决直接在初始化时按 3.1 节的方式做 DPR 缩放。canvas.width cssWidth * dpr之后所有绘图和命中检测都保持在 CSS 像素坐标下工作物理像素交给ctx.scale(dpr, dpr)处理。注意在命中检测的第一层坐标换算里也要同步乘上这个比例否则画布物理宽和显示宽不一致时点击会偏一个固定比例。5.3 快速连点同一座位pending 状态与交互锁现象用户在选座时快速双击或者手抖连点两下结果同一个座位发出了两次选座请求后端生成了两条锁定记录。原因很直接第一次请求还没返回座位状态还是 available第二次点击照样通过校验。解决除了 pending 状态反馈还可以加一个交互锁。点击事件处理函数开头判断如果座位状态是 pending直接忽略本次点击。这个逻辑要在状态切换之前判断不能等setSeatStatus执行完再判断。// 点击座位事件pending 状态下的重复点击直接拦截 function onSeatClick(seatId) { const seat seatMap.get(seatId); if (!seat || seat.status pending) return; if (seat.status sold || seat.status disabled) return; selectSeat(seatId); }这段代码的关键是查 seat 对象当前状态再决定是否继续。如果你把判断写在selectSeat内部就可能出现请求已经发出、状态已经改成 pending但事件回调还没更新 UI 的窗口期连点漏洞还是存在。交互锁和 pending 状态配合才能完全杜绝这类问题。5.4 iframe 嵌入后鼠标位置偏移getBoundingClientRect 坐标修正现象座位图嵌入后台系统的 iframe 或第三方页面后点击座位总是往右边偏几十像素而且不同位置偏移量不同。原因在于event.clientX是相对于浏览器视口的页面有滚动条或 iframe 本身在页面中有偏移时直接用clientX - rect.left得到的并不是画布坐标。解决用getBoundingClientRect拿到 canvas 相对视口的位置这个值已经包含了滚动和 iframe 偏移不需要再手动加window.scrollX。但要注意 iframe 内页面如果嵌在一个居中容器里rect.left就是容器相对视口的距离这样换算出来的坐标才对。一个额外的坑是画布元素被 CSS 缩放比如transform: scale(0.8)时getBoundingClientRect返回的是变换后的尺寸坐标换算必须按 3.2 节的scaleX width / rect.width来修正不能直接用物理宽除 CSS 宽。5.5 座位多到 2000 个后卡成笔电风扇狂转局部重绘代替全量重绘现象座位数量超过一千后鼠标每次移动座位图都明显迟滞CPU 占用暴涨。原因是鼠标移动事件触发了整张画布的全量重绘每次都要重新遍历两千个座位并执行绘图命令。这个问题在需求评审阶段不容易暴露因为演示数据大多是几十个座位。解决把重绘拆成两个级别。鼠标移动时先记录当前 hover 座位的 id判断它和上一次 hover 的座位是否相同不同才重绘。而且重绘时只画两个座位上一个 hover 座位的正常状态和当前 hover 座位的高亮状态。// 局部重绘只在 hover 变化时绘制两个座位 let lastHoverId null; function onMouseMove(e) { const hit hitTest(e, layout, seatSize); const hoverId hit ? hit.id : null; if (hoverId lastHoverId) return; if (lastHoverId) drawSeat(allSeatMap.get(lastHoverId)); if (hoverId) drawSeat(allSeatMap.get(hoverId), { hover: true }); lastHoverId hoverId; }选中、取消选中、状态变更同样走这个局部重绘路径。只有在缩放、平移、初次渲染或区域整体高亮时才走全量重绘。这个优化做完之后两千座位的画布在普通笔记本上都能保持流畅的交互响应。更激进的做法是使用ctx.save和ctx.restore把每个座位画在独立图层上但一般局部重绘已经足够不要过度设计。6. 让座位图真正「互动」起来缩放平移与区域联动选座6.1 缩放平移的两种实现canvas transform 与手动重算坐标座位图不带缩放平移在大厅场景下基本不可用。超过一百个座位如果画布不够大又不允许缩放用户就只能眯着眼找座位。Zoom 和 Pan 有两种实现路径一种是把缩放和平移作用在 Canvas 的变换矩阵上每次重绘之前ctx.setTransform(scale, 0, 0, scale, tx, ty)适合整张画布只有座位图一种内容的情况另一种是手动重算所有座标的 layout Map放大两倍就把每个座位坐标乘二适合需要保留原始像素坐标做持久化的场景。我推荐前一种因为简单且性能好变换矩阵由 GPU 加速修改后只需要一次全量重绘不需要重新计算两千个座位的坐标。监听滚轮事件以鼠标位置为缩放中心公式是newTx scaleCenterX - (scaleCenterX - oldTx) * newScale / oldScale这一步处理不好会出现「缩放时内容往角落跑」的漂移。平移通过 mousedown 加 mousemove 实现记录起始点坐标差更新tx和ty。实践中最容易翻车的是缩放中心计算一定要按上面的公式做等比换算不能直接改 scale 值。6.2 联动点击区域列表高亮对应座位反向同步真实的票务系统不只卖座位还要让用户按区域浏览。侧边栏显示区域列表鼠标悬停到「VIP区」时座位上对应区域整片高亮点击后只显示该区域座位。实现思路是按 sectionId 分组渲染高亮时给该区域所有座位加一个半透明遮罩或边框加粗。// 区域悬停为指定区域的所有座位追加高亮标记 function highlightSection(sectionId) { const affected seatList .filter(s s.sectionId sectionId) .map(s s.id); affected.forEach(seatId { const seat seatById.get(seatId); drawSeat(seat, { highlight: true }); }); }反向联动指的是用户鼠标在画布上悬停某个座位时侧边栏同步高亮显示它所属的区域和价格信息。这个反查操作在数据模型是「区域 座位」两级结构时很简单座位对象里有 sectionId直接找到区域对象更新侧边栏 DOM。反向联动的交互价值在于用户不需要提前知道区域分布鼠标扫一遍就能发现「原来这片区域是普通区价格 88」。实现时把 DOM 更新放在绘制代码之后避免频繁操作 DOM 造成卡顿。6.3 验证与性能测试一张 2000 座位的厅怎么用十分钟自测开发完不是看一眼主观觉得「好像挺流畅」就上线。我给自己定的自测流程是先写一个坐标一致性校验脚本遍历所有座位对每个座位中心点调用一次 hitTest确认返回的恰好是它自己再模拟随机点击 500 次确认选中的座位状态变更、总数不超 maxSelect最后用性能面板做长任务检测确认在 2000 座位的画布上鼠标快速移动时没有超过 50ms 的长任务。// 自测脚本验证 layout 与 hitTest 的坐标一致性 function sanityCheck(layout, seatSize) { let passCount 0, failCount 0; for (const { x, y, seat } of layout.values()) { const hit hitTest({ clientX: x, clientY: y, target: canvasEL }, layout, seatSize); if (hit hit.id seat.id) passCount; else failCount; } console.log(pass${passCount}, fail${failCount}); }这个脚本里直接把clientX和clientY设为座位中心坐标如果画布发生滚动或缩放脚本也需要先同步到对应状态。我习惯把它做成一个开发环境下可手动触发的函数用 URL hash 控制开关生产环境不打包进代码。性能验证我一般用一个简单的经验值座位数乘以交互帧率如果乘积低于三万说明当前交互路径还有优化空间。比如 2000 个座位加 60 帧交互乘积是 12 万远超三万就应该检查是不是出现了全量重绘循环。做了几年这类地图和座位图组件我最大的习惯是先把坐标一致性校验写出来再写业务逻辑。坐标对不上后面所有交互都是空中楼阁坐标对了状态管理反而简单。这套方法帮我避开了好几个临近上线才发现点击错位的尴尬场景希望帮到你。本文还有配套的精品资源点击获取