冲突处理核心是让冲突可见、可追溯、可安全合并，需采用ot或crdt算法，配合本地优先策略与状态同步机制，而非锁或强顺序；websocket层须保障有序、带序号的消息传递与断线增量恢复。
WebSocket 实现的实时协作编辑器中，冲突处理的核心不是避免冲突，而是让冲突可见、可追溯、可安全合并。关键在于采用操作变换（OT）或 CRDT 等一致性算法，配合合理的本地优先策略和状态同步机制，而非依赖锁或强顺序。
用 OT（Operational Transformation）解决并发编辑冲突
OT 是协作编辑领域最成熟的技术路径。它要求所有编辑操作（如插入、删除）被抽象为可交换、可变换的操作对象，并在广播前对操作进行“变换”以适应其他用户已提交的变更。
- 每个操作携带时间戳或序列号（如基于 Lamport 逻辑时钟），服务端按全局顺序排序并分发
- 客户端本地执行操作时，先暂存；收到他人操作后，用 OT 函数将本地待发操作与之变换，再发送
- 例如：用户 A 在位置 5 插入 “x”，用户 B 同时在位置 5 删除字符；B 的删除操作需被变换为作用于插入后的文本（即位置 6），否则直接应用会导致错位
- 开源参考：ShareDB、TogetherJS、CodeMirror 6 的 collab extension 均基于 OT
用 CRDT 实现无中心协调的最终一致
CRDT（Conflict-Free Replicated Data Type）通过数据结构自身保证多副本并发更新后能自动收敛到相同状态，不依赖服务端排序，更适合 P2P 或弱网场景。
- 常用文本 CRDT 包括 Logoot、RGA（Replicated Growable Array）、LSEQ —— 它们为每个字符分配唯一且可比较的标识符（如向量时钟+客户端ID+序号）
- 插入操作带位置锚点（前驱/后继 ID），删除仅标记为 tombstone，合并时按 ID 全序重排即可
- 优势是离线编辑天然支持、服务端逻辑极简；缺点是内存开销略高、调试难度大
- 实践建议：前端可用 Yjs（RGA 实现）或 Automerge（JSON-CRDT），搭配 WebSocket 进行二进制增量同步
WebSocket 层必须保障的操作语义
无论选 OT 还是 CRDT，WebSocket 协议层需提供基础支撑，不能只做透明管道：
- 消息需带 clientID + seqNum，服务端记录各客户端最新已确认序列，支持断线重连后的操作补发（not just resync whole doc）
- 禁用无序接收：启用 message ordering（WebSocket 本身保序，但需避免多连接/多 channel 混淆）
- 心跳 + 重连机制中，重连成功后应请求“自上次 seq 起的增量操作日志”，而非全量 reload，防止丢失本地未提交变更
- 服务端可做轻量校验：拒绝明显越界的删除位置、重复 seq、伪造 clientID 的操作包
用户体验层面的冲突提示与降级策略
算法再健壮，用户也需要感知协同状态。纯后台 merge 不等于“无感”：
- 显示他人光标/选区（用 color-coded floating tooltip），并标注用户名，让用户预判可能的干扰区域
- 当检测到高频局部编辑（如 3 秒内同一段落被 2+ 人修改），临时加灰提示“多人正在编辑此处”，不阻塞，但提升注意力
- 允许手动触发“rebase”：用户可选择将自己全部未提交更改，基于当前服务端最新快照重新变换并提交，用于解决长时间离线后的复杂偏差
- 极端情况（如 OT 变换失败、CRDT 解析异常）降级为“只读模式 + 弹窗引导刷新”，并保留本地草稿到 localStorage
不复杂但容易忽略：冲突处理成败不在算法多精巧，而在操作建模是否完整（比如是否支持格式属性、表格行列增删）、状态同步是否原子（一次操作 ≠ 一次 DOM 更新）、以及错误是否可逆回滚。WebSocket 是通道，真正决定体验的是你在上面跑什么协议、怎么定义“一个编辑”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
