我之前帮朋友做过类似的协作文档项目，一开始也踩过diff-match-patch的坑，跟你遇到的问题一模一样——并发修改后补丁乱套，出来的结果完全没法看。后来研究了Google Docs、Figma这些产品的底层逻辑，才明白核心是要从**“同步文档状态差异”转向“同步用户操作本身”**，目前业界成熟的有两种核心思路，结合你的场景给你拆解一下：

一、操作转换（OT）：Google Docs早期的核心玩法 #

核心逻辑 #

不再生成整个文档的diff补丁，而是把用户的每一次编辑拆成细粒度的操作指令（比如“在索引15处插入字符‘6’”、“从索引15开始删除4个字符”），服务器会维护文档的版本号，当收到用户的操作时，先检查这个操作基于的文档版本是不是最新的：

• 如果是最新的，直接应用操作并同步给所有用户；
• 如果不是（比如你例子里用户2先提交了修改），服务器会把这个操作转换为适配最新版本的指令，再应用，最后同步转换后的操作给所有用户。

针对你场景的解决过程 #

拿你举的例子：

• 初始版本V0：Stack overflow is 55666.
• 用户2先提交操作：[删除索引15-19的5个字符，插入“25552”]，文档升级到V1：Stack overflow is 25552.
• 用户1提交的操作是基于V0的：[删除索引15-18的4个字符，插入“6”]
• 服务器收到用户1的操作后，发现它基于V0，而当前版本是V1，就会把用户1的操作转换为：[删除索引15-19的5个字符，插入“6”]，应用后得到正确的Stack overflow is 6.，再同步给所有用户。

体验优化点 #

• 本地即时反馈：用户编辑时，先在本地应用操作，让用户马上看到效果，后台异步同步到服务器，即使后续有操作转换，也只需要微调局部，不会打断用户体验；
• 版本号追踪：给每个操作标记对应的文档版本，服务器只需要处理版本差的转换逻辑，避免全量同步；
• 离线缓存：用户网络差时，本地缓存未提交的操作，等网络恢复后批量提交，服务器会批量转换并同步。

二、无冲突复制数据类型（CRDTs）：Figma、Notion用的现代方案 #

核心逻辑 #

和OT不同，CRDTs的核心是让每个操作都可交换、幂等——不管操作的执行顺序如何，所有用户的文档最终都会自动收敛到同一个正确状态，不需要服务器做复杂的操作转换，冲突解决在客户端本地就能完成。

具体实现时，每个编辑单元（比如每个字符）都会被分配一个唯一的全局标识符（比如包含用户ID、时间戳的组合），当多个用户同时编辑时，客户端会根据标识符的规则（比如时间戳晚的优先、用户ID优先级）自动合并操作，不需要人工干预。

针对你场景的解决过程 #

还是你的例子：

• 初始文档里的“55666”每个字符都有唯一ID；
• 用户1的操作是：[删除ID为A、B、C、D、E的字符，插入ID为F的字符“6”]；
• 用户2的操作是：[删除ID为A、B、C、D、E的字符，插入ID为G、H、I、J、K的字符“25552”]；
• 当两个操作同步到对方客户端时，因为原始的5个字符已经被双方都删除了，客户端会根据操作的时间戳（比如用户2先提交，时间戳更早）或预设规则（比如用户ID大的优先）自动选择保留哪个插入内容，最终所有用户的文档状态一致。

体验优化点 #

• 零感知冲突解决：大部分冲突会在本地自动处理，用户几乎感觉不到同步的存在；
• 离线友好：支持离线编辑，重新联网后自动同步合并，不需要用户手动处理；
• 低服务器压力：服务器只需要转发操作，不需要做复杂的转换计算，适合大规模用户场景。

三、为什么你的diff-match-patch方案会出问题 #

diff-match-patch是基于当前文档状态生成的补丁，本质是“从状态X到状态Y的变更”，它完全依赖原始状态X。当并发修改时，目标状态已经变成了Z，再把X→Y的补丁套到Z上，就会出现错位——比如你例子里用户1的补丁是删除“55666”的前4个字符，但用户2已经把“55666”改成了“25552”，应用补丁后就会错误删除“25552”的前4个字符，得到“252”这种混乱结果。

四、落地时的额外建议 #

不管选OT还是CRDTs，都可以搭配这些细节优化体验：

• 细粒度操作拆分：把连续输入的字符合并成一个操作（比如每200ms合并一次），减少网络请求量；
• 局部同步：只同步发生变化的区域，而不是整个文档，提升同步速度；
• 可选的冲突提示：对于极少数无法自动解决的冲突（比如两个用户同时删除同一个段落），可以给用户一个温和的提示，比如“有其他用户同时编辑了这段内容，已自动合并”，尽量避免打断用户；
• 操作历史回溯：记录所有操作历史，用户可以随时回溯到之前的版本，万一合并出问题也能快速恢复。

内容的提问来源于stack exchange，提问作者Rahul