连续赶了两个通宵终于把“第三次作业”交上去了。这标题看着像大学里随手起的一个课程名实际上算是我最近忙活最久的一个小项目一整套带实时协作、在线白板功能的课程设计作业。这次不是简单的“做个网页就行”而是要把前后端、通信协议、数据同步、异常处理全走一遍做完之后收获确实不小。这篇博文就围绕这次“第三次作业”展开把我从选型、搭框架、写代码到踩坑修复的完整过程写下来。题目听起来普通但实际上牵涉到实时通信、Canvas 绘图、状态同步、多人协作冲突处理这些内容适合正在做类似课程设计、毕业设计或者想入门全栈协作应用的同学参考。我会把关键代码、参数配置、排错思路全放出来尽量让你照着走也能跑通。1. 整体设计思路与项目目标1.1 题目看起来简单实际需求拆解出来很吓人说句实话最初看到“第三次作业”这个标题我第一反应是“随便做点东西交上去就行”。但等听完成绩评定标准我才发现这题目根本不是“做个静态页面”那么轻松。它的完整要求是做一个支持多人在线协作的白板系统用户可以在同一个画布上绘制图形、拖拽元素、添加文字其他在线成员能实时看到彼此的操作并且支持多人同时编辑互不干扰。这个需求一拆解立刻牵扯出一串技术点前端画布渲染用 Canvas 还是 SVG元素怎么管理实时通信轮询、SSE、WebSocket 怎么选数据一致性多人同时画线、拖拽、删除时状态怎么同步冲突处理两个人同时改同一个矩形的位置以谁为准房间管理不同用户进入不同白板互不影响图形编辑选中、移动、缩放、旋转这些基本交互怎么实现工程结构代码不是堆一个页面而是要有清晰的前后端分层这些都是实打实的工程问题任何一个都能写几千字。所以做完之后回头看这个“第三次作业”其实是一个低配版的在线设计工具原型。1.2 技术方案选型为什么这么选选型这一步我纠结了很久也试过几个方案最后敲定的是前端用原生 JavaScript Canvas后端用 Node.js 原生 ws 库通信协议为 WebSocket数据存储用内存加 JSON 文件持久化。先说为什么不用框架。最初我想过用 Vue 或 React因为组件化确实省事。但后来考虑了一下白板这种高频操作场景核心在于 Canvas 重绘和 WebSocket 消息分发框架带来的渲染优化优势不明显反而会引入一层额外的响应式转化逻辑。原生 JavaScript 写这类应用事件监听和绘图逻辑反而更直白调试也少绕弯路。如果你想练手用 Vue 其实也可以但核心绘图代码一定要和框架逻辑解耦。后端没有用 Socket.io先用 ws 库原因是这次作业在局域网环境跑没有跨网段消息推送需求Socket.io 的自动降级、房间管理、断线重连这些特性虽然好用但作业场景用不上那么重的东西。直接基于 ws 手写一个消息路由逻辑简单结构透明出问题也好查。数据持久化这块我没有引数据库用的是 JSON 文件定期落盘。白板操作频率高如果每次操作都写数据库IO 开销会很明显而且这次作业的数据量很小一个房间的图形元素撑死几百个JSON 文件存起来完全够用。你要是做一个生产系统这里换成 Redis 加 Postgres 更合理但作为课程设计简单可靠优先。1.3 整体架构一览整个系统是典型的前后端分离结构浏览器端负责画布渲染和交互用户在白板上画画、拖拽、输入文字所有操作产生一次事件例如“新增矩形”“移动圆形”前端会把事件封装成一条标准消息通过 WebSocket 发给服务端。服务端不存具体图形数据的所有逻辑它只做三件事接收消息、广播给房间里其他客户端、把消息追加到历史记录里。新用户加入房间时服务端会把历史记录打包发给他这样新成员就能看到之前其他人画的内容。消息流转的大致路径是用户A操作白板 → 前端生成 JSON 消息 → 通过 WebSocket 发送给服务器 → 服务器校验并广播 → 用户B、C、D收到消息 → 各自前端把图形更新渲染到画布这个结构其实已经在模仿真实协作文档应用的雏形了核心是消息格式的统一理解。只要消息协议定得好前后端各写各的基本不会出大问题。2. 核心技术细节解析2.1 WebSocket 连接管理与数据同步机制WebSocket 是这次作业的通信基石连接管理是我花最多时间反复调的部分。首先一个最基本的问题客户端什么时候发起连接连接我采用的做法是页面加载后立即建立 WebSocket 连接同时向后端发起一个“加入房间”的握手消息。这个握手消息里携带房间号服务端根据房间号维护一张连接表。连接表的结构很简单就是对象加数组// 服务端连接管理 const rooms { room-001: { clients: new Set(), // WebSocket 实例集合 history: [] // 该房间的历史操作消息 } };每个客户端连接建立时先通过 message 事件解析房间号然后把当前连接塞进对应房间的 clients 集合。核心点在于服务端不限制一个房间的客户端数量连接数只受系统文件描述符限制。这次作业测试环境只有十来个人在线完全没压力。数据同步机制我用的是“增量广播 全量快照补偿”的组合策略。每次操作只广播一条增量消息比如“新增圆形”“移动矩形”接收方解析完消息后更新本地画布元素数组然后触发重绘。而新成员加入时直接收一份历史消息列表逐条回放就能得到完整的画布状态。这样做的好处很直接在线用户只需要处理增量消息带宽占用小离线用户重连后通过全量快照恢复状态不会丢数据。代价是历史记录会无限增长所以还要配套做清理策略比如只保留最近 30 分钟的操作或者定期把图形元素快照存成一个文件启动时加载到历史记录首部。2.2 消息协议字段设计一条消息如何做到不重不漏消息协议是协作系统的命脉。前端和后端之间传输的每条消息必须有明确的字段含义。我定义的消息格式长这样{ type: draw, action: add, shape: rect, data: { id: 1001, x: 150, y: 200, width: 100, height: 60, fill: #ff0000, stroke: #000000 }, roomId: room-001, sender: user_abc, time: 1714000000000 }看一遍字段大概能猜到作用type 表示消息大分类本次只用了 draw、cursor、system 三类比action 表示具体动作add、update、deleteshape 表示图形类型data 存具体坐标和样式参数roomId 是路由标识sender 用于区分消息来源time 是时间戳解决顺序冲突用的。时间戳特别关键。在多人协作场景下网络延迟会导致消息乱序。假如 A 先移动了一个矩形B 后删除了它但 A 的消息因为网络原因后到那最终状态就错了。解决思路有两个第一服务端收到消息后统一打上自己的时间戳再广播不信任客户端时钟第二客户端在处理消息时先校验该消息操作的元素是否还存在如果元素不存在就丢弃消息。两个方案我同时用了效果还可以。2.3 Canvas 渲染优化与元素数据结构设计画布渲染是前端最耗性能的部分。我刚开始写的时候每次操作就清空画布重新绘制图形一多就出现肉眼可见的闪烁。后来意识到了问题所在白板应用和游戏渲染还不一样它不是每帧都在跑而是只有操作发生时才更新。但即便如此频繁的 clearRect 加重绘也会造成性能浪费。优化思路是分层渲染。底层放一个静态画布用于画那些长时间不变的图形元素上层放一个动态画布专门用于绘制当前正在编辑的元素比如正在拖动中的矩形边框、光标位置提示。每次操作发生时动态画布清空重绘操作结束时才把结果写入底层画布。这个策略让复杂场景下的渲染压力减少了很多。图形元素的数据结构也是一个要注意的点。我用一个统一对象描述所有图形class Shape { constructor(type, data) { this.id data.id || generateId(); this.type type; // rect | circle | line | text this.x data.x || 0; this.y data.y || 0; this.props {}; // 不同图形类型有不同的额外属性 this.visible true; this.createTime Date.now(); } }这样设计的好处是画布数据集合只需要维护一个数组不同图形通过 type 区分。绘制时用一个 switch 分发到不同的绘制函数结构清晰测试也好写。2.4 坐标系统与图形命中检测坐标系统的处理有个小坑Canvas 的默认坐标系是左上角为原点向右为 x 正方向向下为 y 正方向。这本身没问题问题出在画布尺寸可能随窗口变化而变化。如果前端的画布宽度是 1000后端的某个坐标是 800一旦窗口缩放导致画布实际宽高变化坐标就对不上了。我的应对方案是坐标传输统一用“相对坐标”即 x 和 y 的值永远是画布宽度、高度的百分比。例如 x: 0.35 表示元素中心的水平位置在画布宽度的 35% 处。渲染时前端再根据当前画布实际尺寸换算成像素值。这样窗口尺寸再变图形位置都不会漂移。命中检测是另一个问题。用户点击画布时需要判断点到了哪个图形上。最简单的做法是逆序遍历元素数组因为后画的图形层级更高优先命中。判断规则如下矩形点的坐标落在矩形边框范围内圆形点到圆心的距离小于半径直线点到线段的垂直距离小于阈值比如 5 像素文本点的坐标落在文本包围盒内命中检测用到的数学计算并不复杂但要考虑不同图形的特性不能一刀切。当初我最开始偷懒全部按矩形包围盒算结果点圆形边缘经常误选后来改成按类型精确计算体验立刻上了一个台阶。3. 实操过程与核心环节实现3.1 工程结构组织和初始化项目目录我分得很清楚前端静态文件和后端服务分开放。前端通过 HTTP 访问WebSocket 走单独端口两个服务互不干扰。目录结构大概是这样的whiteboard/ ├── client/ │ ├── index.html │ ├── css/ │ │ └── style.css │ ├── js/ │ │ ├── app.js // 入口及逻辑组装 │ │ ├── canvas.js // 画布操作与渲染 │ │ ├── socket.js // WebSocket 封装 │ │ ├── shape.js // 图形类定义 │ │ └── user.js // 用户及光标管理 ├── server/ │ ├── index.js // HTTP 服务 WebSocket 服务 │ ├── room.js // 房间管理逻辑 │ └── data.json // 持久化数据 └── package.json初始化代码很简单前端页面加载时先创建画布实例然后初始化 WebSocket 连接之后所有操作都通过事件绑定触发。服务端用 express 托管静态文件用 ws 库创建 WebSocket 服务监听一个独立端口。3.2 前端核心实现从交互触发到消息发送前端最核心的一段逻辑是“操作发生时生成消息并发送”我在 canvas.js 里写了一个统一的接口// 画布操作后把所有变更提交给消息中心 function commitAction(actionType, shapeData) { const msg { type: draw, action: actionType, // add | update | delete shape: shapeData.type, data: toRelativeCoordinates(shapeData), roomId: currentRoomId, sender: currentUserId, time: Date.now() }; socket.send(JSON.stringify(msg)); }toRelativeCoordinates 函数负责把像素坐标转换成相对比例坐标这样窗口缩放后信息不会丢。前端还需要监听键盘和鼠标事件比如mouseDown判断是否命中已有图形是则进入拖动模式否则开始绘制新模式mouseMove更新拖动的图形坐标并把临时状态画在下层画布mouseUp正式提交操作调用 commitAction 发送消息文字输入稍复杂一点因为需要弹出输入框。我临时在画布上方叠加一个隐藏的 input 元素点击画布文字区域时定位该 input 并触发 focus回车后把内容写进图形数据结构再提交消息。3.3 后端核心实现消息路由与广播策略服务端消息处理核心我写了一个消息分发函数。它的逻辑不复杂但消息类型的细分和校验很重要function handleMessage(ws, rawMsg) { let msg; try { msg JSON.parse(rawMsg); } catch (e) { sendError(ws, invalid_json); return; } if (!rooms[msg.roomId]) { rooms[msg.roomId] createRoom(msg.roomId); } const room rooms[msg.roomId]; switch (msg.type) { case join: room.clients.add(ws); ws.roomId msg.roomId; sendHistory(ws, room.history); broadcast(room, buildPresenceMsg(room)); break; case draw: const stampedMsg stampAndValidate(msg); if (stampedMsg) { room.history.push(stampedMsg); broadcastExcept(room, stampedMsg, ws); } break; case cursor: broadcastExcept(room, msg, ws); break; default: sendError(ws, unknown_type); } }这里有几个细节值得注意。一是历史记录只在成功校验通过的消息才追加避免垃圾数据污染后续加入的成员状态。二是广播时排除发送者自己因为发送者本地已经渲染过了重复收到消息再渲染会闪烁。三是照顾到消息类型分支清晰将来扩展新消息类型只需要在 switch 里加一个 case不改动其他逻辑。服务端还要处理一个边界情况客户端断开连接。WebSocket 的 close 事件必须触发房间内成员清理否则积攒大量死连接会越跑越卡。我的处理是在 close 里调用一个 leaveRoom 函数同时广播一条成员退出消息让前端刷新在线成员列表。3.4 联调测试两个浏览器模拟多人协作联调这一步我用的是最朴素但特别实用的土办法开两个浏览器窗口一个 Chrome一个 Edge设置不同的 userId加入同一个房间然后分别在两个窗口里画图、拖动、删除观察画面是否同步。测试过程中最容易暴露的问题有三个第一个是消息乱序导致元素状态错乱。表现为 A 窗口添加了一个矩形但 B 窗口收不到或者收到了但位置不对。排查方法是在浏览器控制台打印所有收发的消息逐步对照时间戳和元素 id。第二个问题是 Canvas 大小不一致导致坐标偏移。A 窗口比较宽画的图形在 B 窗口里位置偏了。这就是相对坐标没有生效检查 toRelativeCoordinates 的换算公式是否前后一致。第三个问题是焦点丢失。文字输入时点一下空白区域正在编辑的输入框失去焦点导致内容丢失。解决的方案是在输入框失焦时自动提交当前内容而不是等到回车才提交。4. 常见问题与排查技巧实录4.1 WebSocket 连接频繁断开这个问题在最初版本里很突出打开页面大概十秒左右连接就会断开服务端没有任何报错前端也没有主动关闭连接。后来发现是某些后端服务器默认对空闲连接超时如果没有心跳包维持活跃状态就会被底层清理掉。解决办法是加心跳机制。客户端每 30 秒发送一条{ type: ping }消息服务端收到后回复{ type: pong }。同时服务端启动一个定时器每 60 秒检查一次所有连接的最后活跃时间超过 90 秒没有消息就主动断开。这个机制一加连接稳定多了整个联调过程中再没出现无故断线。代码实现大概是// 客户端 setInterval(() { if (socket.readyState WebSocket.OPEN) { socket.send(JSON.stringify({ type: ping })); } }, 30000);4.2 新加入用户看不到历史图形这是最开始没设计历史记录机制时撞上的问题。新用户打开页面后WebSocket 连接建立成功也能收到后续新增的图形消息但画布上空空如也看不到其他人之前画的内容。这就是缺少全量状态同步的表现。解决方案我前面已经说过服务端为每个房间维护历史消息数组新成员 join 时一次性发送全部历史。但这里有个性能隐患如果历史消息数组无限增长新成员加入时消息量会非常大。我的折中做法是每过 5 分钟把当前房间画布的元素数组转成一条特殊快照消息插到历史记录头部同时清空旧消息。新成员加入时先恢复快照再回放快照之后的增量消息。4.3 多人同时编辑同一图形后操作覆盖前操作这个问题的出现场景是用户 A 和用户 B 同时把同一个矩形往两个相反方向拖动两边都提交后最终位置取决于服务端先收到谁的消息。后来的消息覆盖先到的导致先操作的人出现“被拽回去”的感觉。要彻底解决需要上 OT 算法或 CRDT对于课程设计来说太重了。我采用的是轻量级方案给每条图形数据增加版本号服务端只处理版本号大于当前版本号的消息旧消息直接丢弃。具体逻辑写在 stampAndValidate 函数里function stampAndValidate(msg) { const room rooms[msg.roomId]; const target room.history.filter(h h.data.id msg.data.id).pop(); if (!target) return msg; const currentVer target.version || 0; const incomingVer msg.version || 0; if (incomingVer currentVer) return null; msg.version currentVer 1; return msg; }这个方案能解决多数简单的并发覆盖问题。真正复杂到需要多版本合并的场景课程设计不会涉及但如果你要做生产级系统还是要深入研究 OT 和 CRDT。4.4 图形一多就卡顿画布里有超过 200 个图形元素后每次拖动和绘制都会有明显的卡顿。这一开始让我很头疼因为测试时图形数量根本不到五十个结果给老师演示时大家乱画一通瞬间几百个图形在线整个页面就开始掉帧。排查后定位到两个性能瓶颈第一个是每次操作都全量重绘。解决方法是引入脏矩形机制只重绘发生变化的那一小块区域。但脏矩形在图形密集时计算复杂我最终选择的分层渲染加局部刷新方案。第二个是消息风暴。有用户在短时间内连续画几百条线每条线都生成一条消息服务端逐条广播客户端的队列瞬间积压。我的解决办法是引入消息合并机制短时间内同类型同元素的消息合并成一条例如拖动过程中连续产生的坐标变化只保留最新的终点坐标。4.5 浏览器兼容性和设备适配经验测试时发现Chrome 下运行的代码在 Safari 里偶尔出现 canvas 渲染异常主要原因是不同浏览器对 Canvas 的某些 API 支持有细微差别比如roundRect方法在部分浏览器版本没有实现还有setLineDash的虚线样式解析结果不一。处理策略是不用太新或太偏门的 API边框圆角用原生 rect 加 arc 手动绘制虚线为了避免兼容问题直接用短线段模拟。这虽然麻烦但兼容性确实提升了。移动端触摸事件也需要注意触屏设备上不会触发 mouse 系列事件需要额外监听 touchstart、touchmove、touchend 并做坐标换算。临近交作业前我把所有浏览器兼容问题汇总成了一张快速排查表方便你们以后自己写前端项目时对比现象最常见原因快速解决连接反复断开缺少心跳包加 30 秒 ping/pong图形位置漂移坐标不是相对值统一使用百分比坐标多人操作覆盖版本号未校验按元素 id 维护递增版本新用户空白历史记录未同步快照增量回放图形一多就卡全量重绘分层渲染局部刷新5. 作业复盘与踩坑心得回看这次“第三次作业”技术上的收获其实比我想象中大得多。完整做一个前后端分离的实时协作应用涉及的知识面非常广。从 WebSocket 长连接管理、消息协议设计、坐标系统转换到 Canvas 性能优化、多端一致性问题每一块都有值得深挖的内容。踩了这么多坑最后挑几个最想提醒你们的话说一下第一消息协议一定要在一开始就定好不要写一半再改。我最初因为时间紧消息字段起得很随意后来加字段时要把所有相关代码都过一遍浪费了不少时间。要是早一点把 type、action、shape、 data 这套结构确定下来后面可以省很多事。第二坐标系统和心跳机制这种“看起来不重要”的事千万不要偷懒。坐标不对整个白板全乱套没有心跳连接普遍活不过一分钟。越是基础的东西越要提前做好。第三多利用浏览器的性能面板去看页面渲染耗时分布。卡顿问题不要瞎猜把面板打开录一段操作观察哪个函数执行时间最长对症下药远比盲调有效。这次拖动卡顿的根因就是靠 recording 时发现 fillText 函数占了 60% 的耗时然后改进了字体缓存才彻底解决。第四课程设计的时间大概率比你想的要紧张。不要总是等到临交前几周才开始动手早期先定好架构、搭好骨架、把基础流程跑通后期只需要不断加功能和修 bug心态会稳很多。这次的工程其实从第一次上手到基本能跑只花了一周多一点但后面折腾兼容性和性能花了不少时间。这个项目最终交上去拿到了不错的评价。但说实话真正让我觉得值回票价的不是评分而是整个过程中我对实时协作应用底层逻辑的理解。以后如果再让我做一个协同编辑器、在线会议白板甚至更复杂一点的多人在线设计工具我已经知道从哪下手、有哪些坑绝对不能踩。如果你们也接到类似的“第三次作业”希望这篇东西能帮上点忙。内容已经敞开在这里了代码骨架和排查思路都能直接拿来参考剩下的就是你自己动手把细节啃下来。
