关键不在“连上”，而在“怎么传、怎么画、怎么不乱”：需统一JSON消息格式（含type/data/id/ts）、前端节流打包渲染、服务端仅广播不存状态、房间隔离+白名单校验+断线重连补发。
用 WebSocket 实现多端协同白板同步，关键不在“连上”，而在“怎么传、怎么画、怎么不乱”。核心是把用户操作变成轻量结构化消息，服务端不做判断只广播，前端收到后立刻重绘——整个链路要短、快、稳。
定义统一的操作消息格式
所有端（PC、平板、手机）必须遵守同一套 JSON 协议，避免解析歧义。推荐字段包括：
-
type：标识操作类型，如
"stroke"（自由笔迹）、"rect"（矩形）、"template:change"（背景切换） -
data：携带具体内容，例如笔迹用
{ points: [{x:100,y:200}, {dx:3,dy:-2}], color: "#2563eb", width: 3 }，用相对偏移（delta）压缩数据体积 -
id：每条操作唯一标识（如
"u7-20260915-0042"），便于后续支持撤销/重做或冲突排查 - ts（可选）：毫秒级时间戳，离线重连后可用于排序或丢弃过期指令
前端节流+打包+安全渲染
鼠标或触控移动时，mousemove 或 touchmove 每秒触发几十次，不能每次发一条消息：
- 用
requestAnimationFrame聚合一帧内的所有点，再打包成单个stroke消息发出 - Canvas 绘图前校验坐标是否在合理范围内（如 ±10000），防止恶意数据撑爆内存或触发渲染异常
- 背景模板切换时，只接受预设白名单 ID（如
["blank", "grid-10", "lined"]），拒绝任意 URL 或路径，防 XSS - 不同用户用固定色板区分（如用户 A 总是
#3b82f6，B 是#ef4444），颜色由服务端分配或前端基于 userId 哈希生成，不依赖客户端上报
服务端只中继、不存状态、不校验
WebSocket 服务端应保持极简逻辑，专注连接管理和广播：
立即学习“Java免费学习笔记（深入）”；
- 收到某用户消息后，立即向同房间（room ID 匹配）所有其他在线客户端广播，不修改、不验证、不排序
- 房间隔离靠
roomId字段实现，例如连接时发送{ type: "join", roomId: "proj-abc123" }，服务端据此分组 - 不维护“当前模板是什么”“谁画了第几笔”等全局状态，这些由前端自己管理并初始拉取（首次加载通过 HTTP GET /api/board/:id 获取快照）
- 断线重连后，前端先拉最新快照，再订阅 WebSocket，服务端补发重连期间的增量消息（需搭配简单消息队列或内存缓存最近 30 秒消息）
处理多端差异与基础容错
手机触控、PC 鼠标、平板手写笔行为不同，但消息结构一致：
- 移动端用
touchstart/touchmove/touchend替代 mouse 事件，归一化为 clientX/clientY 坐标再处理 - Canvas 渲染前统一缩放适配：记录画布逻辑尺寸（如 2000×2000），UI 层按视口缩放绘制，避免不同设备像素比导致线条粗细不一致
- 网络抖动时，前端对重复消息做简单去重（检查 id + ts 窗口），服务端不做 dedup —— 复杂逻辑交给客户端更灵活
- 连接断开时本地暂存未确认操作（带本地 id），重连成功后重发；服务端不负责 ACK，靠前端超时自动重试（最多 2 次）
