关键在于构建协同感知的本地操作栈、服务端操作广播及冲突规避机制：以用户操作单元建模Operation对象，WebSocket仅广播结构化操作而非画布状态，撤销仅回退本地操作并通知他人淡化对应图形，通过版本向量保障跨客户端操作顺序与视觉一致。
要实现网页版多人在线涂鸦板的多层级撤销管理，关键不是单纯靠 WebSocket 传输画笔数据，而是设计一套**协同感知的本地操作栈 + 服务端操作广播 + 客户端冲突规避与状态同步机制**。WebSocket 负责低延迟通信，但撤销逻辑必须在客户端分层维护，同时避免多人操作引发的历史错乱。
一、本地多级撤销栈：按“用户操作单元”而非“单点坐标”建模
把一次拖拽、一个图形（如矩形/文字）、一次颜色切换等视为一个可撤销的 Operation 对象，而非记录每一帧鼠标移动。每个 Operation 包含：
- type（"stroke", "rect", "clear" 等）
- payload（路径点数组、起止坐标、样式哈希等）
- timestamp 和唯一 clientOpId（用于去重和排序）
- 可选：关联的 canvas state snapshot（仅对复杂操作做轻量快照，避免内存爆炸）
客户端维护两个栈：
- undoStack：存放已执行、可撤销的操作
- redoStack：存放刚撤销、可重做的操作
每次用户绘制完成（mouseup 或 touchend），生成 Operation 并 push 到 undoStack，清空 redoStack。
二、WebSocket 协同：广播操作而非画布状态
不发送整张 canvas 图片或 base64，只通过 WebSocket 发送结构化 Operation 消息：
{
"type": "stroke",
"opId": "cli_abc123",
"userId": "u456",
"points": [[100,200],[105,202],...],
"style": {"color":"#ff6b6b","width":3},
"timestamp": 1718234567890
}服务端不做业务逻辑判断，仅做消息广播（或按房间 ID 转发）。所有客户端收到后：
- 验证 opId 是否已处理（用 Set 缓存已接收 opId，防重复）
- 按 timestamp 插入本地操作队列（非立即执行，而是排队渲染）
- 执行时将该 Operation 推入自己的 undoStack（注意：只推入，不触发 UI 撤销）
三、撤销时的协同一致性保障
用户点击“撤销”，只回退自己发起的操作，不影响他人已绘制内容。实现方式：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 每个 Operation 标记
origin: "local"或"remote"；撤销栈只包含origin: "local"的操作 - 撤销时，从 undoStack 弹出最近一条本地操作，用 canvas 2D API 执行逆向擦除（如重绘背景色覆盖笔迹）或恢复前一帧快照
- 同时向服务端发送一条
{"type":"revoke","opId":"cli_abc123"}消息，通知其他客户端：“这个操作对我已撤回”——其他客户端据此隐藏/淡化对应图形（用透明度或虚线样式），但不真正删除，避免二次撤销冲突
四、解决“跨客户端撤销顺序错乱”问题
当 A 撤销了第 3 步，B 却还在第 5 步，如何保持视觉一致？答案是引入协同版本向量（Vector Clock）或逻辑时间戳：
立即学习“前端免费学习笔记（深入）”；
- 每个客户端维护一个递增的
localVersion，每执行一个本地操作就 +1 - 每个 Operation 携带
{ sender: "u456", version: 7 } - 客户端渲染时，按
(sender, version)全局排序所有已接收操作，确保画面重建顺序一致 - 撤销操作也携带当前 localVersion，其他客户端据此判断是否该同步隐藏——例如 B 收到 A 的 revoke(v=3)，而 B 已执行到 v=5，则只隐藏 A 的第 3 步图形，不干扰后续
