WebSocket在协作画板中传输的是结构化操作指令而非画面，如stroke/circle/clear等JSON消息，含type/id/points/attrs字段，客户端按统一逻辑还原；需节流打包、时间戳排序、历史补发及断线重连保障一致性。
WebSocket 在协作式在线画板中不是“传输画面”，而是让所有人同步操作意图——它把每个用户的笔迹、清空、换色等动作，变成轻量、可重放的指令，实时广播给所有参与者，再由各自浏览器精准还原。关键不在传图，而在传“怎么做”。
消息必须结构化，不能依赖原始像素或 DOM
直接同步 Canvas 的 toDataURL() 图片或 SVG 字符串会迅速拖垮带宽和渲染性能。正确做法是定义统一的 JSON 操作协议，例如：
-
type:"stroke"（画线）、"circle"（画圆）、"clear"（清空）、"setColor"（改色） -
id: 用户唯一标识（如"user_abc123"），用于区分笔迹归属与颜色 -
points: 坐标数组，如[[120,80], [125,83], [132,87]]，支持连续笔迹压缩 -
attrs: 可选样式，如{ color: "#2ecc71", lineWidth: 4, tool: "pen" }
所有客户端用同一套解析逻辑处理这些数据，才能确保不同设备上画出的线条位置、粗细、颜色完全一致。
高频操作要节流+打包，避免网络风暴
鼠标或触控移动时，mousemove/touchmove 每秒可能触发数十次。如果每次点都发一条 WebSocket 消息，不仅浪费连接资源，还容易造成客户端渲染卡顿或顺序错乱。实用策略是：
- 起笔（
mousedown/touchstart）立即发stroke_start消息 - 移动中每 30–50ms 采集一次新点，攒够 4–6 个坐标再打包发送
stroke消息 - 抬笔（
mouseup/touchend）发stroke_end，提示路径闭合或结束
这样既保持视觉流畅性，又大幅降低帧频压力。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
新用户加入时得“看到已有内容”，不能只等新操作
刚连上的用户如果只接收后续消息，画布就是空白的——协作体验直接断裂。解决方法是服务端维护一个滚动操作日志（比如最近 15 秒内存队列），格式与实时消息完全一致。用户连接成功后，立刻推送这批历史操作，并标记 "isHistorical": true。前端收到后跳过动画、撤销栈记录等交互逻辑，直接批量绘制。
顺序不等于到达顺序，必须靠时间戳或序号排序
真实网络中，TCP 层可能重排、合并小包，导致 WebSocket onmessage 触发顺序 ≠ 发送顺序。尤其多人快速绘图时，这点极易引发画面错乱。因此：
- 每条消息必须携带
timestamp（毫秒级）或sequenceId（单调递增） - 客户端收到后暂存进缓冲队列，按时间戳排序后再逐条消费
- 自动丢弃比当前已处理最大时间戳早 500ms 以上的旧消息，防止延迟累积
服务端不做重排序，只原样广播，保证低延迟与架构简洁。
基础稳定性不能省：断线、重连、重复连接都要有兜底
- 用户意外断开时，服务端标记其状态，并广播
"user_left"事件 - 重连时尽量复用原
id和颜色配置，避免身份丢失或风格突变 - Canvas 尺寸建议控制在合理范围（如 2000×2000），配合
transform缩放容器实现“无限画布”，避免内存溢出
不复杂但容易忽略。
