WebSocket本身不解决冲突，仅提供传输管道；消息顺序一致性取决于消息结构设计、客户端还原逻辑与服务端广播策略三者协同——真实网络中message到达顺序≠发送顺序，需依赖timestamp或sequenceId排序缓冲、节流批量发送、历史补发及坐标标准化转换。
直接说结论：WebSocket 本身不解决冲突，它只是管道；真正决定协作是否靠谱的，是消息结构设计 + 客户端还原逻辑 + 服务端广播策略——三者缺一不可。
为什么 WebSocket 收到的消息顺序会乱？
真实局域网或公网环境下，message 到达客户端的顺序 ≠ 发送顺序。尤其当用户快速拖动画笔、频繁触发 mousemove 时，多个小包可能被 TCP 重排或合并。
- 不要依赖
send()调用顺序来保证渲染一致性 - 每个消息必须带可排序字段：
timestamp（毫秒级）或sequenceId（单调递增整数） - 客户端收到后先暂存进缓冲队列，按
timestamp排序再批量消费，丢弃比当前最大timestamp小 500ms 的旧包 - 服务端不做重排序，只做“原样广播”，避免引入额外延迟和状态维护成本
stroke 消息怎么发才不卡、不丢、不糊？
直接在 mousemove 里每点都 send() 是最常见错误——既压垮 WebSocket 帧频，又让客户端渲染压力爆炸。
- 采用“节流 + 批量”策略：监听
mousemove，每 40ms 截取一次新点，攒够 4–6 个再打包成一个{type:"stroke", id:"u1", points:[[x1,y1],[x2,y2],...], attrs:{color:"#3498db", lineWidth:2}} - 起笔（
mousedown）单独发{type:"stroke_start", id:"u1"}，抬笔（mouseup）发{type:"stroke_end", id:"u1"}，方便客户端做路径闭合或优化 - 禁用
touch-action: none以外的全局阻止行为，否则移动端touchmove可能被浏览器吞掉 - Canvas 渲染时，对同 id 同 color 的连续
points合并为单条 path，避免反复调用ctx.beginPath()和ctx.stroke()
新用户加入时，为什么看到的是空白画布？
因为只监听了“实时广播”，没处理“历史补发”。新连接上来那一刻，服务端默认不推任何旧数据。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 服务端需维护最近 15 秒的操作日志（内存队列即可），格式与实时消息完全一致
- 用户连接成功后，服务端立即推送这批日志，带上
isHistorical: true标识，客户端跳过动画、直接绘制 - 客户端收到
isHistorical消息时，禁用本地操作拦截（比如不触发撤销栈记录），避免把补发动作误当用户输入 - 不建议全量 dump 历史——画布操作不是文档，超过 30 秒的数据对协同意义极低，反而拖慢首屏
clear 或 color change 操作为什么不同步？
这类控制指令常被当成“UI 状态”本地处理，没走 WebSocket 广播通道，结果只有自己看到变化。
- 所有影响共享画布状态的操作，必须走统一消息通道：
{type:"clear"}、{type:"set_color", color:"#e74c3c"}、{type:"set_tool", tool:"eraser"} - 服务端不做语义解析，只做透传；客户端收到后，先更新本地状态，再执行对应 UI 变更（如切换工具按钮高亮）
- 避免在客户端用
ctx.clearRect()直接清空——应改为绘制一个覆盖全画布的白色rect，确保该操作可被其他客户端复现 - 颜色/粗细等属性变更，必须绑定到
id上，否则多人同时切色会导致混乱（比如 A 切红、B 切蓝，但没人知道谁该用哪个）
最容易被忽略的点：Canvas 坐标是相对容器的，而不同设备屏幕缩放、DPR、滚动偏移都会导致 clientX/clientY 解析出错。务必在采集坐标前统一转换为 canvas 像素坐标，且所有客户端使用同一套转换函数——这个细节一旦漏掉，同步就只是“看起来像”，实际永远对不齐。
