加锁不解决协同编辑冲突，只导致卡顿和误判；真正有效的是ot算法实现操作可交换、可追溯、可变换，配合本地暂存与变换广播确保最终一致性。
协同编辑里加“并发锁”是典型南辕北辙——它不解决冲突，只制造卡顿和误判。真正需要的不是锁住别人，而是让所有操作可交换、可追溯、可变换。
为什么 lock / unlock 消息在协同编辑中基本无效
很多团队一遇到两人同时改同一段就想着加锁：A 编辑时发 {"type":"lock","range":[5,10]}，B 尝试编辑就弹窗“已被锁定”。这在技术上能实现，但实际带来一堆问题：
- 网络延迟下，
lock消息可能晚到，B 已经完成输入并发出变更，服务端再收到锁请求时已无法撤回 - 用户关闭标签页或断网，
unlock永远不会到达，锁永久挂起，需额外心跳+超时机制兜底 - 锁粒度难定：按整文档？太粗；按字符位置？光标微移就频繁加锁，体验僵硬；按语法块？解析成本高且边界模糊
- 锁掩盖了真实问题——操作语义丢失、无序到达、未变换合并——只是把冲突从“内容错乱”转成“用户抱怨不能编辑”
替代方案：用 OT + 本地暂存 + 变换广播代替锁
真正落地的协同编辑，靠的是操作抽象与变换，而不是阻塞。关键点在于客户端不直接应用本地操作，而是先排队、等对齐、再变换、最后提交：
- 用户输入时，前端生成原子操作对象，如
{type:"insert", pos:7, text:"x", clientId:"c123"}，暂存在本地待发队列，不立即 apply 到编辑器 - 收到他人操作（如
{type:"delete", pos:6, length:1, clientId:"c456"}）后，调用 OT 函数transform(localOp, remoteOp)，把本地插入位置从 7 变为 8（因前面删了一个字符） - 服务端不转发原始操作，而是按逻辑时钟排序后广播变换后的版本，并附带
version或seq字段，客户端据此丢弃重复或过期消息 - 编辑器最终只响应经过变换、带合法
clientId的操作——自己发的不重复渲染，别人发的才触发 UI 更新
真要“视觉锁定”，该怎么做才不翻车
如果产品确实需要提示“有人正在编辑某段”，那必须是轻量、临时、可撤销的视觉反馈，而非服务端强制拦截：
- 前端监听光标移动和选区变化，在本地计算活跃范围（如最近 2 秒内被鼠标 hover 或 focus 过的 DOM 节点），生成
{type:"presence", range:[120,135], userId:"u777", ts:1717724701} - 服务端不做校验，只做有序广播（按
ts去重，3 秒未更新自动过期） - 接收方只在对应 range 上叠加半透明色块或边框，不阻止输入；用户点击该区域时，可主动聚焦并拉取最新状态，而非报错
- 绝对禁止把
presence当作权限依据——它只是辅助信息，不能用于拒绝insert或delete操作
最易被忽略的一点：所有操作消息里的 pos 和 length 必须基于纯文本偏移（即 document.textContent 的索引），而不是 HTML 字符串或 DOM 节点位置。一旦混用，OT 变换立刻失效，后续所有同步都会错位。这点在富文本编辑器（如 Slate、TipTap）里尤其容易踩坑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
