V3.02.2Non-destructive conflict resolution设计
冲突需保留双方版本
别名: 非破坏性冲突解决 · 双版本保留 · 冲突保全
概念解释
冲突发生时，系统必须把两个版本都留下来，再让人决定怎么办——这是非破坏性冲突解决的底线。它不负责替人裁决谁对谁错，只负责保证裁决发生之前，任何一方的工作都不会作为冲突的副作用消失。用户面对的界面可以是并排对比、可以是先后选择、可以是手工拼合，但无论选了什么，没被采纳的那个版本仍要可找回。这与「自动合并」是互补关系：自动合并处理的是互不干涉的并发，冲突保留处理的是真的撞在一起、需要人来判断的并发。
机制
冲突的解决权在人，而人需要时间与信息：另一方不在场、看不全两份修改的意图、需要等更了解上下文的人回来。保留双方版本实质是把「解决冲突」这件事从保存时刻解耦出来——保存时不必立刻分出胜负，冲突被冻结成一个可延后处理的对象。这带来两个直接后果：一是决策质量，人在充分对照后做的取舍，远好于系统在毫秒间的任意裁决；二是心理安全，贡献者的工作不会因为「别人也改了这处」这个与质量无关的事件而消失，才有人愿意直接在共享空间里投入。技术上这要求冲突状态的存储与呈现分离：内容层同时持有两个版本，界面层才谈得上怎么展示取舍。
边界
保留不等于永久堆放。双方版本是待决状态，不是第三种正文；长期无人处理的冲突会积累成「冲突债」，让人望而生畏，最终整个区域被绕开。保留的时限与呈现的显眼程度要随内容重要性分级：主线代码的冲突必须立刻阻塞并解决，草稿区的冲突可以温和提示、限期清理。另外，保留双方版本解决的是内容层的安全，不解决理解层的问题——为什么冲突、对方意图是什么，那是上下文的职责，两条机制配套才完整。
怎么落地
- 冲突界面并排展示双方版本时，「采用我方／采用对方／手动融合」之外必须留「稍后处理」，且稍后处理的入口要能重新找回（冲突清单、待办标记）。
- 被放弃的一方进入版本历史或冲突存档，明确标注来源与时间，而不是丢弃。
- 冲突数量大时提供按区域分组的冲突清单，让解决可以分批进行，避免一次性吓退用户。
- 验证：走查产品里每一条会产生冲突的路径，检查「未采纳版本」在 30 天后是否仍可恢复；找不到恢复入口即不合格。