多人在线文档同时编辑互不覆盖？拆解 OT/CRDT 协同底层原理，看懂本地 Word 无法实时同步的根源

接好运鸭

飞书、腾讯文档、石墨、Google Docs 都能支持十几人同时在一份文档内打字，各色光标实时浮动，所有人的文字、格式修改完整留存，不会互相覆盖。很多人误以为只是网速更快，实际上这是分布式系统深耕三十余年的经典难题。
日常微信来回转发本地 Word，稍微多人同时编辑就会出现内容丢失、版本打架，核心是二者底层同步逻辑完全相反。本文梳理协同技术演进全流程，通俗拆解OT 操作变换、CRDT 无冲突复制数据两大主流算法，对比本地文件与云端文档本质差异，搭配 Git 版本控制类比，把实时协作的底层逻辑讲透。

一、协同编辑两大淘汰原始方案（本地 Word 的通病来源）


在 OT、CRDT 成熟之前，行业曾尝试两种简易方案，均存在致命体验缺陷，也是普通 Word 转发文件频繁丢内容的根源。

1. 覆盖式保存（最后写入优先）


逻辑：每次保存会上传一整份完整文档快照，后保存的文件直接覆盖此前所有修改。
痛点：两人同时编辑文档，晚一步保存的人会直接清空对方全部文字，加班整理的内容凭空消失，微信互传 Word 就是典型的该模式。

2. 悲观独占锁机制


逻辑：文档被一人打开编辑后直接上锁，其他人仅能只读查看，必须等对方关闭文档才能编辑。
痛点多人开会同步记录只能轮流打字，协作效率极低，早年内网老旧办公系统大量采用这套方案。

核心矛盾根源


每台电脑本地存储的都是独立完整文档副本，网络存在延迟、操作到达顺序混乱，直接合并必然出现字符偏移、文字覆盖；传统 “传递完整文件” 的思路，从底层无法解决并发冲突。

二、在线协同核心颠覆思路：不传完整文件，只传微小操作


传统 Word 传递的是文档最终成品快照；云端在线文档只同步用户每一步微小操作：插入文字、删除字符、换行、调整格式、光标移动等轻量化指令，而非整份文件。
举直观实操案例：
用户 A 在第 88 个字符位置插入文字 “项目方案”；
用户 B 同步在第 50 位删除一个逗号；
云端服务器接收两条操作后，自动动态修正 A 的插入坐标，适配文档字符偏移，再同步给所有在线客户端；
两端分别执行修正后的操作，最终所有设备文档完全对齐，无文字错乱、丢失。
页面浮动光标也是独立同步指令，跟随文本偏移实时更新位置，不会出现光标飘走、找不到编辑区的问题。

三、两大主流协同算法：OT 操作变换 VS CRDT 无冲突数据


1. OT 操作变换（代表产品：Google Docs、腾讯文档、飞书文本层）


工作原理


依靠中心化服务器充当统一 “时序裁判”，全局固定操作顺序。远端操作抵达时，服务器结合本地已完成的修改，动态变换操作坐标，适配当前文档长度，保证所有客户端执行结果完全一致。

优缺点


✅ 优势：内存开销极低，在线高频打字延迟小，纯文字场景流畅度拉满；
❌ 短板：高度依赖中心服务器，离线编辑、网络乱序场景处理逻辑复杂，容错能力弱。

2. CRDT 无冲突复制数据（代表：Figma、Notion、Yjs 协同框架）


工作原理


为每一个字符、段落分配全局唯一身份 ID 与固定排序权重，无需服务器统一排序。无论操作先后、网络延迟高低，所有设备独立合并文档时，依靠字符 ID 的数学规则，自动收敛至完全相同的文档版本。

核心优势


原生支持离线编辑，高铁、无网环境写完内容，联网后自动合并，不会丢失任何修改；支持去中心化 P2P 协同，不依赖单一服务器节点。

短板


每个字符需要附带元数据记录 ID，文档存储占用更高，超长纯文本性能弱于 OT。

OT 与 CRDT 核心对比表

对比维度	OT 操作变换	CRDT 无冲突复制数据
核心逻辑	服务器统一调整操作坐标	字符自带唯一 ID，数学规则保证合并一致
服务器依赖	必须中心化云端服务端	支持离线、点对点自主合并
离线编辑适配	适配差，合并逻辑繁琐	原生完美支持离线撰写
内存占用	极低，仅记录操作指令	偏高，存储字符元数据
主流产品	Google Docs、飞书 / 腾讯文档	Figma、Notion、在线白板

国内办公产品通用工程方案


主流在线文档采用混合架构：纯文字实时编辑层使用 OT 压低延迟，表格、画布、离线缓存模块引入 CRDT，平衡流畅度与弱网、离线兼容性。

四、为什么微信互传本地 Word，永远做不到实时协同？


本地 Word 文件与云端在线文档底层同步逻辑存在三层本质差异，无法实现多人实时同步：

• 同步载体完全不同
  Word 传递完整文件快照，保存即全覆盖；在线文档实时推送单条操作指令，仅同步局部改动。
• 缺少统一云端调度中枢
  本地文件分散存储在各人电脑，无中央服务器实时修正字符偏移；在线文档依托云端统一调度全部操作时序。
• 原生独占文件锁机制
  本地 Word 打开文件后自动上锁，禁止多人同时编辑；仅微软 365 存入 OneDrive 云端的 docx 支持轻度协同，且存在段落锁定、延迟卡顿问题Microsoft ...。
  通俗总结：来回转发 Word 是 “交换成品文件”，在线协同是 “同步每一步修改动作”，前者天然存在内容覆盖风险。
  

五、延伸类比：协同编辑与 Git 代码合并底层同源逻辑


程序员常用 Git 分支合并，和在线文档协同底层解决思路高度相通：

• Git：多人修改不同代码文件，提交后批量合并，同一行代码修改需要人工解决冲突，属于异步批量合并；
• OT/CRDT 在线文档：毫秒级实时同步每一次输入，系统自动修正字符偏移，实时消解冲突，属于实时连续合并。
  二者核心目标一致：让多份独立副本最终收敛为统一完整内容，仅同步时效、自动冲突处理能力存在巨大差距。
  

六、办公场景协同工具选型实用建议

• 多人实时开会、同步记录：优先飞书 / 腾讯 / 石墨在线文档，OT+CRDT 混合架构，无内容丢失风险；
• 仅线下传阅、无需实时协作：使用本地 Word，转发时标注版本号，避免多人同时修改；
• 经常出差、网络波动大：优先 CRDT 架构产品（Notion、在线白板），离线写完联网自动同步；
• Microsoft 生态用户如需协同：文件必须存入 OneDrive 云端，本地存储 Word 不支持多人实时编辑。
  

文末总结


多人在线文档同时编辑互不覆盖的核心，是抛弃 “传输完整文件快照” 的传统模式，改用轻量化操作指令实时同步，依靠 OT、CRDT 两套分布式算法自动修正字符偏移，从根源解决并发覆盖问题。
本地 Word 依托文件覆盖 + 独占锁，底层架构天然无法实现流畅实时协同。OT 适合在线高频文字编辑，CRDT 擅长离线、设计画布类协同，主流办公产品采用混合架构平衡体验与兼容性。分清 “同步操作” 和 “交换完整文件” 的本质区别，就能避开版本冲突、文字丢失的日常办公痛点。