websocket仅提供实时传输通道，协同编辑一致性需依赖ot或crdt算法：ot适合顺序敏感文本，通过操作变换保证有序；crdt如y.text基于因果关系实现离线一致。消息须含docid、clientid、op、时间戳，服务端严格有序广播，客户端断线重连需拉取快照+增量日志。
WebSocket 本身不处理冲突，它只是实时传递操作的管道。真正解决多人同时编辑时内容错乱、覆盖、丢失等问题，靠的是上层的一致性算法和协同协议设计。核心思路不是“阻止冲突”，而是“让冲突可计算、可合并、最终一致”。
选择并实现一致性算法
必须在服务端和客户端统一采用 OT 或 CRDT 其中一种，不能混用：
- OT（操作变换）：适合结构清晰、顺序敏感的文本编辑。每个插入/删除操作携带位置和内容，并附带序列号或逻辑时间戳；服务端按全局顺序排队，客户端收到他人操作后，先对本地待发操作做“变换”，再发送。例如两人同时在第10位插入字符，后到的操作会被自动偏移到新位置，避免错位。
-
CRDT（无冲突复制数据类型）：如 Yjs 中的
Y.Text，把文档建模为带唯一ID和因果关系的原子操作集合。所有客户端独立应用变更，无需服务端排序，网络恢复后自动收敛。更适合弱网、P2P 或需要离线强一致的场景，但内存占用略高。
消息结构与传输保障
WebSocket 层要为上层算法提供可靠基础：
- 每条编辑消息必须含
docId（标识文档）、clientId（用户身份）、op（操作体，如{type:"insert", index:5, text:"a"}）、timestamp或seq（用于排序或因果推断）； - 服务端需保证同一房间内消息按时间/序号严格有序广播，避免因网络抖动导致客户端计算路径不同；
- 客户端断线重连后，不能只补最后一条，而应拉取“快照 + 增量操作日志”，确保重放过程与在线时一致。
前端渲染与状态同步分离
避免直接操作 DOM 或编辑器内部状态：
- 所有编辑操作先交由协作引擎（如 ShareDB 的
Doc或 Yjs 的Y.Doc）处理，它负责冲突合并与状态维护； - 编辑器（如 CodeMirror、Monaco、Quill）仅作为视图层，监听协作引擎的状态变更事件，再调用其 API 更新光标、选区、内容；
- 用户光标和选区需单独同步（如通过
cursor:update消息），并标注所属用户，避免本地光标被远程操作意外覆盖。
兜底与可观测性设计
再完善的算法也需应对极端情况：
- 当检测到连续多次操作无法安全变换（如严重时钟漂移或恶意数据），触发服务端强制下发全量文档快照，重置客户端状态；
- 记录关键操作日志（含客户端ID、时间、操作摘要），支持事后追溯谁在何时做了什么；
- 前端展示“正在同步”提示，对高频输入做防抖或批处理，减少无效消息，提升响应感。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
