必须压缩坐标、节流采集、打包发送：用 requestanimationframe 批量收集 3–5 点，首点绝对坐标、后续传 dx/dy，浮点四舍五入至整数或 1 位小数，stroke 整体封装广播，服务端不校验不重排，前端批量渲染并启用本地预绘制。
直接传原始浮点坐标会卡顿，不是 websocket 不行，而是数据结构没压缩、采集没节流、发送没打包。
mousemove 里直接 send() 是最大陷阱
鼠标移动每秒触发 60+ 次，mousemove 回调里一拿到 {x: 123.456789, y: 67.890123} 就调 socket.send()，等于把浏览器采样率原封不动塞进网络——结果是几百条小包挤在 TCP 队列里，触发 Nagle 算法、服务端广播压力飙升、前端渲染排队，最终表现为线条断续、他人看到的轨迹跳变。
- 必须用
requestAnimationFrame或setTimeout(..., 0)批量收集当前帧内所有点，避免阻塞主线程 - 攒够 3–5 个点再发，不是“等松手”，而是“等帧结束”
- 首点保留绝对坐标，后续点只传
dx/dy（delta 编码），例如{"dx": 2, "dy": -1}比{"x": 125, "y": 66}少 6–8 字节 - 整段笔迹封装为一个
stroke对象，含id、points（压缩后数组）、color、width，别拆成几十个单点事件
浮点坐标四舍五入到整数或 1 位小数
Canvas 像素级渲染根本不需要 6 位小数精度。x: 123.456789 JSON 序列化后占 11 字节，转成 x: 123 或 x: 123.5 直接省掉 30%~50% 体积，且人眼和设备分辨率完全无感。
- 前端采集时就做处理：
Math.round(x)或parseFloat(x.toFixed(1)) - 服务端不做二次校验——加这一步平均多耗 0.1ms，千人并发就是百毫秒级延迟累积
- 注意：缩放画布时，坐标需先反向映射回原始画布尺寸再取整，否则缩放后精度错乱
服务端广播前不重排序、不合并、不校验
白板同步的时序一致性靠前端保障，服务端角色必须极简：收到即广播。任何干预都会引入延迟与复杂度，且收益为零。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 不维护向量时钟，不按客户端时间戳重排——同一笔画的点必须按序到达，跨笔画顺序无关紧要
- 不校验
color格式或x/y范围，JSON 解析失败由前端捕获并丢弃整条消息 - 唯一例外是
clear类指令，建议加"priority": "high"字段，确保它不被卡在长队列末尾 - 断线重连补全靠前端主动拉取快照（如最近 10 秒
stroke列表），而不是让服务端实时排序重发
前端接收后必须批量还原，不能逐点 stroke
收到一个 stroke 消息，如果对每个 points[i] 都调一次 ctx.lineTo() 再 ctx.stroke()，CPU 和渲染管线立刻过载。
- 用
beginPath()→moveTo(first.x, first.y)→ 循环lineTo()→ 一次性stroke() - 高密度笔迹场景下，优先用离屏
canvas预渲染路径，再贴图到主画布 - 本地预绘制（local echo）必须开启：用户下笔立即画自己屏幕，同时发指令；收到服务端回传后再微调，防网络抖动偏移
- 新用户加入时，服务端补发的是完整
stroke列表，前端按 id + timestamp 合并渲染，而非逐条 replay
最容易被忽略的其实是“不做什么”：不重排、不校验、不逐点渲染、不在主线程密集计算——这些克制比加功能更难，也更重要。
