直接传原始坐标点会卡顿，因高频mousemove触发大量未压缩消息，导致TCP延迟、服务端压力和渲染排队；需节流、差分编码、打包发送，并优化前端渲染。
为什么直接传原始坐标点会卡顿
用户拖动画笔时，mousemove 每秒触发 60+ 次，若每次都将 {x: 123.45, y: 67.89} 原样发一次，单次绘图可能产生几百条消息。WebSocket 帧本身开销小，但高频小包仍会触发 TCP Nagle 算法、增加服务端广播压力、前端渲染排队——最终表现为“画线断续”“他人看到的轨迹跳变”。
关键不是 WebSocket 不行，而是没做数据节流和结构压缩：
- 原始浮点坐标（如
123.456789）JSON 序列化后占 10+ 字节，可四舍五入到整数或保留 1 位小数（123.5）省 30%~50% 体积 - 连续点之间用相对偏移（delta）代替绝对坐标，比如第二点比第一点多
{dx: 2, dy: -1}，比发两个完整对象更紧凑 - 服务端不做合并，前端也不做防抖，就等于把鼠标采样率直接搬上网络
send() 前必须做的三件事：节流、差分、打包
不要在 mousemove 回调里直接调 socket.send()。正确做法是攒一批点，再统一发一条指令：
- 用
requestAnimationFrame或setTimeout(..., 0)批量收集当前帧内所有移动点，避免阻塞主线程 - 对点序列做 delta 编码：首点保留绝对坐标，后续每点只传
dx/dy，前端接收后累加还原 - 将多段笔迹（如一次按下-移动-抬起）封装成一个
stroke对象，含id、points（压缩后数组）、color、width，而非拆成几十个moveTo/lineTo单点事件
示例压缩后数据结构：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
{"type":"stroke","id":"u1-20260522-001","points":[{"x":100,"y":200},{"dx":5,"dy":2},{"dx":-3,"dy":8}],"color":"#333","width":2}
服务端广播前要不要校验或重排序
不需要。WebSocket 白板场景下，服务端角色应极简：收到即广播，不干预时序、不校验合法性、不合并指令。原因很实际：
- 校验坐标范围或颜色格式会增加每条消息的 CPU 开销，实测在 Node.js
ws库中，单条校验平均多耗 0.1ms，千人并发就是百毫秒级延迟累积 - 重排序需维护客户端时钟或向量时钟（Vector Clock），复杂度陡增，而白板操作天然具备局部性——同一笔画的点必须按序到达，跨笔画的顺序无关紧要
- 真正需要处理的是“断线重连后如何补全”，这靠前端在
onopen后主动拉取最新stroke快照，而不是让服务端实时排序
唯一建议的轻量处理：对 clear 类指令（如清空画布）加优先级标记，确保它不被卡在长队列末尾。
前端渲染时怎样避免卡顿和重绘撕裂
Canvas 渲染慢，不是因为画得复杂，而是因为频繁调用 beginPath/moveTo/lineTo 触发路径重建。同步来的每条 stroke 都该批量绘制：
- 不要逐点调用
lineTo；把整个points数组解压为绝对坐标后，用ctx.setLineDash([])+ctx.stroke()一次性描完 - 开启离屏 Canvas 缓存：先在
offscreenCanvas上画好整条笔迹，再用drawImage贴到主画布，减少主渲染线程压力 - 监听
visibilitychange事件，页面切后台时暂停接收新stroke消息（避免积压），切回前台再恢复并批量重绘
最容易被忽略的一点：别在 onmessage 里直接操作 canvas.getContext('2d')。把它包装进 queueMicrotask 或 requestIdleCallback，让渲染让位于用户交互响应。
