WebSocket仅提供通道，协作靠服务端OT/CRDT算法；前端需捕获结构化原子操作（如insert/delete）、带version校验、精确应用；须用成熟库（如ShareDB、ot-json0）避免手写，前后端逻辑对齐。
WebSocket 本身不实现协作，它只提供低延迟双向通道；真正让多人编辑不乱套的，是服务端的 OT（操作变换）或 CRDT 算法，配合前端精确的操作捕获与应用逻辑。
必须用结构化操作，不能发整份文档
每次用户输入、删除或格式化，前端应生成类似这样的原子操作对象，而不是发送整个文档字符串：
- type：明确为 "insert" 或 "delete"，避免模糊字段如 "update"
- index：基于当前文档状态的逻辑位置（UTF-16 code unit），不是 DOM 坐标或字节偏移
- text（插入时）或 length（删除时）：携带实际变更内容
- version 或 seq：服务端统一打戳的版本号，或客户端本地递增序列号，用于排序和去重
服务端不能只做消息中转
收到操作后，Spring Boot 或其他 Java 后端需立即执行三步处理：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 校验该操作是否来自合法会话（docId + clientId 有效且未过期）
- 比对当前文档 version，拒绝旧版本操作（防止重放或网络延迟导致的倒退）
- 调用 OT 变换函数：例如用户 A 在位置 5 删除 2 字符，而用户 B 刚在位置 4 插入 3 字符，则需将 A 的删除位置自动前移为 8，再应用——这类规则必须覆盖所有操作组合
前端要对接编辑器底层事件，不是监听 input
用 tui.editor 就监听 change 和 caretChange；用 CodeMirror 6 就取 Transaction.changes；避免绑定 textarea.oninput 或调用 setValue() 这类覆盖式方法。
- 每次操作生成后，先暂存到本地
pendingOps队列，支持断线重连时合并重发 - 收到服务端推送的操作，必须用与后端完全一致的
apply()函数执行，建议前后端共用同一套操作应用逻辑（JS/TS 模块或 Java/JS 算法严格对齐） - 光标、选区等 UI 状态需单独同步，不能依赖内容更新自动恢复
别从零手写 OT，优先集成成熟方案
Java 后端可用 ShareDB 或 ottypes；Node.js 环境推荐 ot-json0；前端务必消费它们输出的标准 op 结构，而非自定义格式。
- 这些库已覆盖 insert/delete/format 的全部变换组合，手写极易遗漏边界情况
- 它们天然支持 version 校验、rebase 通知、serverTimestamp 对齐等关键能力
- 服务端返回的每条消息若含
rebase: true，前端必须按新 index 重算并应用，不能硬套原始位置
