WebSocket实现文档锁机制不可行，因其无法解决协同编辑中操作无序、语义丢失与合并问题，反而导致卡顿、误判和死锁；正确方案是采用操作变换（OT）模型，通过结构化操作、本地暂存、服务端排序与变换、轻量presence提示来保障最终一致性。

直接用 WebSocket 实现“文档锁机制”不是可行方案——它解决不了协同编辑的本质问题，反而会引发卡顿、误判和死锁。真正需要的不是阻止别人编辑，而是让所有操作可交换、可追溯、可合并。

为什么加锁在协同编辑里行不通

很多团队一看到两人同时改同一段，就想着发 {"type":"lock","range":[5,10]} 拦住对方。但这在真实网络环境下几乎必然失效：

• 网络延迟下，锁消息晚到，B 已完成输入并发出变更，服务端无法撤回
• 用户关页或断网，unlock 永远不达，锁长期挂起，必须额外加心跳+超时兜底
• 锁粒度难平衡：按整文档太粗，按字符位置太敏感（光标微移就频繁锁），按语法块又解析成本高、边界模糊
• 锁掩盖了真实问题——操作无序、语义丢失、未变换合并——只是把内容错乱换成“不能编辑”的抱怨

真正该用的操作同步模型

协同编辑的核心是操作抽象与变换，不是阻塞。关键在于客户端不直接应用本地操作，而是排队、对齐、变换、再提交：

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

• 本地输入先暂存为结构化操作，如 {"type":"insert","index":7,"text":"x","clientId":"c123"}，不立即渲染
• 收到他人操作（如 {"type":"delete","index":6,"length":1}）后，调用 OT 函数 transform(localOp, remoteOp)，自动把插入位置从 7 变为 8
• 服务端按逻辑时钟或 seq 排序，广播变换后的操作，并附带 version 或 serverSeq 字段，客户端据此丢弃重复或过期消息
• 编辑器只响应经过变换、带合法 clientId 的操作——自己发的不重复渲染，别人发的才触发 UI 更新

如果真要“视觉提示有人在编辑”

可以有，但必须轻量、临时、不可控权限——它只是辅助，不是拦截依据：

• 前端监听光标移动和选区变化，本地计算活跃范围（如最近 2 秒内被 focus 的 DOM 节点），生成 {"type":"presence","range":[120,135],"userId":"u777","ts":1717724701}
• 服务端不做校验，只做有序广播（按 ts 去重，3 秒未更新自动过期）
• 接收方仅在对应 range 上叠加半透明色块或边框，不阻止输入；用户点击该区域时，可主动聚焦并拉取最新状态
• 绝对禁止把 presence 当作权限依据——它不参与任何操作校验或拦截逻辑

Java 后端必须补的关键环节

Spring Boot + @ServerEndpoint 默认只是消息中转，远远不够。你得在收到操作后、广播前插入三步处理：

• 校验 docId + clientId 是否在有效会话中，防伪造请求
• 查缓存获取当前文档 version，拒绝旧版本操作（防重放）
• 调用 OT 引擎（如 ot.js 或 operational-transform）对并发操作做 transform 和 compose，确保最终一致性