OT还是CRDT？序列编辑多人协同防冲突的选型逻辑与工程实践

一个被低估的问题：两个人改同一行，系统到底发生了什么

序列编辑——无论是文本、代码还是视频时间线——一旦引入多人协同，立刻面临一个核心矛盾：两个人同时修改同一个位置时，谁说了算？

这个问题在单体编辑器中根本不存在。你一个人写文档，光标在哪改到哪。但一旦打开协作开关，每一次按键都可能与其他人的操作产生交叉。如果不加处理，后提交的人覆盖前一个人、或者两边改出截然不同的版本，都是大概率事件。

序列编辑多人协同防冲突，本质不是"加一把锁"这么简单，而是一整套从数据结构到传输协议的系统工程。

三种传统做法，为什么都不够好

在讨论主流算法之前，先看几个"直觉上对、实际不够用"的方案：

• 悲观锁：谁先编辑谁锁定该段，其他人只能看不能改。彻底避免了冲突，但多人协作变成了排队等待，完全违背了"协同"的设计初衷。
• 乐观锁：不加锁，提交时检测是否被改过。冲突时弹出提示让用户手动选择。冲突少时可行，一旦并发量上升，用户会被"冲突提示"淹没。
• Diff-Patch：类似Git的差异补丁方案，生成diff去合并。问题在于它基于行或块，颗粒度太粗，同一行内的并发修改几乎无法自动处理。

这三种方式都有一个共同缺陷：它们假设冲突是"异常"，需要人的判断来介入。但在实时协同编辑中，并发修改才是常态。

OT 算法：把"冲突"变成"转换"

Operational Transformation（操作转换）是解决序列编辑多人协同防冲突的第一个里程碑方案。1989年首次提出，后来被Google Wave大规模应用于生产环境，成为Google Docs的底层核心技术之一。

OT的思路非常简单但优雅：将每次编辑看作一组原子操作——retain（保持N个字符）、insert（插入字符串）、delete（删除字符串）。当两个用户的操作发生交叉时，不是判定谁对谁错，而是通过transform函数，把操作对转换为"可以在对方版本上正确执行"的版本。

举个例子：用户A将"hello, tom!"中的"tom"改为"world"，用户B同时将"hello"改为"hi"。如果顺序执行，B的操作会导致位置偏移，A的delete('tom')会删错内容。OT的transform函数会计算出操作A'和操作B'，确保无论谁先执行、谁后执行，最终两个人都看到"hi, world!"。

OT的局限也很明显：它需要中心服务器协调操作顺序，对网络质量和延迟敏感，且算法复杂度随操作类型增多而指数上升。

CRDT：换一种思路，让冲突"不存在"

如果说OT是"发生了冲突再转换"，那CRDT（Conflict-free Replicated Data Types，无冲突复制数据类型）走的是另一条路：设计一种天然可合并的数据结构，让冲突从数学上就不可能出现。

CRDT的核心基于三条数学性质：交换律、结合律、幂等性。满足这三条的操作，无论以什么顺序执行、是否重复执行，最终结果都完全相同。这就是所谓的"强最终一致性"。

在序列编辑中，CRDT的落地方式很巧妙：不给字符用"位置索引"（第N位），而是给每个字符分配唯一ID，用"在ID=x后面插入"来描述编辑操作。

假设初始文本是"Hi"（H的ID=1，i的ID=2）。用户A插入"e"和"y"（ID=3和4），用户B插入"o"（ID=5）。网络乱序同步后，所有设备按ID排序，最终都是"H e y o i"。没人被覆盖，没有合并冲突，不需要人工判断。

CRDT分两大类：状态型（CvRDT，同步完整状态并合并）和操作型（CmRDT，只传播操作）。协同编辑场景通常用CmRDT，因为传输操作比传输整个文档高效得多。

OT vs CRDT：选型不是二选一

理解这两个算法的区别，比记住定义重要得多。下表总结了核心差异：

实际工程中，两者不是非此即彼。腾讯文档、飞书文档等产品在文本编辑层使用OT保证实时性，在结构化数据层引入CRDT支持离线场景，已经形成了混合架构的工程共识。

从技术到落地：你该关心什么

如果你在做或选一个多人协同编辑工具，序列编辑多人协同防冲突不应该只看"用OT还是CRDT"这种理论标签，更应该关注几个实际维度：

• 操作粒度：是按字符、按单词、还是按块？粒度越细，自动合并能力越强，但元数据开销越大。
• 网络容忍度：能否在断网后继续编辑、重连后自动合并？这决定了一支团队在高铁、咖啡馆的可用性。
• 撤销语义：多人协同下的Ctrl+Z，是撤销"我最后的操作"还是"全局最后的操作"？两者的实现难度天差地别，用户预期也完全不同。
• 冲突可视化：即使大部分冲突能自动解决，用户仍需要知道"别人改了什么"。一个好的diff视图比自动合并更重要——衍因智研云等科研协作平台的做法是将版本变更与审计日志联动，每次编辑都有归属和时间戳，这对需要合规审查的行业尤为重要。

四十年技术演进，才刚刚开始

从1984年MIT提出CSCW（计算机支持的协同工作）概念，到1989年OT算法首次发表，再到2010年代CRDT从学术论文走入Google Docs和Notion的生产环境，协同编辑技术经历了持续四十年的迭代。

到今天，序列编辑多人协同防冲突的底层方案已经相当成熟。但新的挑战正在浮现：AI辅助编辑引入的批量修改如何与人工操作并发合并、跨媒体的协同（同时编辑文本+图片+视频时间线）如何设计统一的数据模型、加密协同编辑如何在不解密的前提下检测和合并冲突——这些问题还没有完美答案。

对于产品和技术选型来说，最好的方案不是最前沿的论文，而是最匹配你实际场景的那一个：实时性优先就用OT，去中心化和离线优先就用CRDT，两者都需要就用混合架构。

以生物医药研发为例，衍因科技的智研云平台在处理多人协同编辑实验记录时，面临的不仅是文本级冲突，还有样品数据、实验步骤和合规审计之间的交叉依赖。平台通过审计日志全程追踪每一次编辑的来源与时间，配合细粒度权限控制，确保协同编辑的可追溯性——这与通用协作工具只关注文本一致性有本质区别。

关键不是消灭冲突，而是让冲突的代价降到用户感知不到的程度。