websocket协作可靠性取决于消息设计、客户端还原和服务端广播三者配合：消息需带timestamp或sequenceid排序去重；客户端缓冲排序并丢弃过期包；服务端原样广播、不重排；绘图操作结构化分段发送；新用户补发15秒历史日志；撤销、光标等状态语义化同步；冲突时快照兜底。
WebSocket 本身只是传输通道，不解决同步逻辑——真正决定协作是否可靠的是消息设计、客户端还原方式和服务端广播策略三者的配合。
消息必须带可排序字段
真实网络中，消息到达顺序不等于发送顺序。尤其在快速拖动画笔时，TCP 可能重排或合并数据包。因此每个绘图消息都要附带 timestamp（毫秒级） 或 sequenceId（单调递增整数），用于后续排序和去重。
- 客户端收到后先暂存进缓冲队列，按时间戳排序再批量消费
- 丢弃比当前最大 timestamp 小 500ms 的旧包，避免渲染过期操作
- 服务端不做重排序，只做“原样广播”，减少延迟和状态维护成本
绘图动作要结构化分段发送
不能在 mousemove 里每动一下就 send() 一次，那样既压垮连接又让渲染崩溃。应采用节流+聚合策略：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 起笔（mousedown/touchstart）单独发
{type:"stroke_start", id:"u1"} - 移动中每 40ms 截取一次新点，攒够 4–6 个再打包为
{type:"stroke", id:"u1", points:[[x1,y1],...], attrs:{color,lineWidth}} - 抬笔（mouseup/touchend）发
{type:"stroke_end", id:"u1"}，方便路径闭合与优化 - 清空、换色、撤销等控制指令也走同一通道，结构统一，不本地处理
新用户加入需补发历史操作
刚连上的用户看到空白画布，是因为只监听了实时广播，没处理历史同步。
- 服务端维护最近 15 秒的操作日志（内存队列即可），格式与实时消息一致
- 用户连接成功后，立即推送这批日志，并带上
isHistorical: true标识 - 客户端收到后跳过动画、直接绘制，且禁用本地撤销栈记录，防止误判为用户输入
- 不建议全量 dump 历史——超过 30 秒的操作对协同意义极低，反而拖慢首屏
撤销与光标等状态必须语义化同步
撤销不是本地行为，而是全局操作指令；光标位置也不能靠 DOM 实时上报。
- 撤销消息结构示例：
{type:"undo", seq:127, byUserId:"u_882", timestamp:1746845940221} - 服务端校验 seq 合法性后再广播，确保所有客户端按相同粒度执行擦除
- 脑图类场景中，拖动节点只同步事件（如
{"event":"nodeDrag","nodeId":"n5","x":120.3,"ts":...}），由各客户端用同一套 JS 引擎重算布局 - 冲突时触发快照兜底：
{"event":"layoutSnapshot","nodes":[...],"version":32}，强制重置视图
