纯WebSocket广播文本快照无法支撑真实协作，因消息乱序导致内容倒退、操作丢失、UI状态不同步、带宽激增；必须用结构化原子操作（含index/timestamp/version）替代快照，并经服务端校验、去重、OT转换后分发，辅以独立光标同步机制。
没有操作转换（OT）或 CRDT，纯靠 WebSocket 广播文本快照，根本撑不住真实协作场景——不是延迟高，就是内容错乱。
为什么直接 send() 整个文档内容会出问题
很多初学者用 WebSocket 实现“协同编辑”时，习惯让前端每次 input 或 change 事件触发后，把整个文档字符串发给服务端，再由服务端 broadcast() 给其他客户端。这看似简单，但实际踩坑密集：
- 网络抖动下，消息可能乱序到达，A 发的第 3 版本比 B 的第 2 版本晚到，导致别人看到的内容“倒退”
- 两个用户同时删同一段，或一人插入、一人删除邻近位置，纯覆盖式同步会让其中一方操作完全丢失
- 光标位置、选区状态、撤回栈等 UI 状态完全无法跟随同步，协作体验断裂
- 带宽和解析开销随文档增长线性上升，10KB 文本每秒发一次，连接数一多就卡顿
onmessage 收到的是操作（op），不是快照
真正可落地的实时同步，必须把“用户做了什么”结构化为原子操作，并附带上下文信息。典型操作结构长这样：
{
"type": "insert",
"docId": "doc-789",
"clientId": "user-a45",
"index": 12,
"text": "React",
"timestamp": 1716919568234,
"version": 42
}
关键点：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
index是基于当前最新版本的逻辑位置，不是 DOM 坐标；需配合服务端维护的文档状态做校准 -
timestamp和version用于冲突排序，不能只依赖客户端时间（误差大），服务端需统一打戳或用向量时钟 - 前端必须监听编辑器底层事件（如
tui.editor的addCommand、quill的text-change），而不是textarea.oninput - 服务端收到后不立即广播，而是先入队、去重、按逻辑顺序归并，再分发
Java / Spring Boot 中处理并发编辑的核心拦截点
在 Spring Boot + @ServerEndpoint 或 WebSocketHandler 场景下，真正的难点不在连接管理，而在操作抵达后的三步处理：
- 校验
docId+clientId是否在有效会话中（避免伪造请求篡改他人文档） - 查缓存获取该文档当前
version，拒绝version <= 已处理最大值的旧操作（防止重放） - 调用 OT 转换函数：比如用户 A 提交
{type:"delete", index:5, len:3}，而用户 B 刚刚在位置 4 插入了 2 字符，则必须把 B 的插入操作先“前移”再应用，否则删除位置错位
别指望手写完整 OT；用成熟库如 ot.js（JS）或 operational-transform（Java）封装好的 transform() 和 compose() 方法，自己只管调度。
前端光标和选区同步常被忽略的细节
用户看不到别人光标在哪，协作感就断了一半。但光标本身不是文档内容，不能混在操作流里粗暴广播：
- 光标位置必须绑定
clientId和docId，且使用独立 channel 或 message type（如"cursor:update"） - 服务端不做合并，只做透传；前端收到后，用 requestAnimationFrame 节流渲染，避免高频抖动
- 选区（selection）需额外记录
anchorOffset/focusOffset，且要处理跨行、跨标签等边界情况；mavon-editor或tiptap提供了getSelection()接口，别自己算 DOM 位置 - 用户切 Tab 或失焦时，应主动发
"cursor:leave"，服务端清理其光标状态，避免残留“幽灵光标”
真正难的从来不是连上 WebSocket，而是让两个互不信任的客户端，在无中心协调的前提下，对同一段文本达成确定性共识。这个共识不靠魔法，靠操作建模、时序控制、以及对编辑器底层事件的精准捕获——漏掉任意一环，实时协作就会在用户最专注的时候，悄悄崩掉。
