多人改同一份 Clash 配置时，文本差异往往混杂真正的列表改动和只存在于呈现层的差异。YAML 加载会丢弃注释、节点样式、标量格式和缩进风格；映射键顺序属于序列化细节，构造时不得依赖。序列是有序条目，次序变化才是内容变化。审查应围绕表示图，而不是把每一处空白都当成冲突。
适用条件
适用于合并他人修改、对照两份 YAML、需要决定哪些列表差异必须保留或回绝的场合。适用于有人把块序列改成了方括号、重排了某个映射里的键、或只改了注释的情况。不适用于比较哪套规则策略更合适。依据 YAML 1.2.2 的表示、序列化与呈现模型。
审查步骤与判断依据
- 先确认双方文本都能解析。格式不良的流无法组成序列化树，应先修成可加载再审内容。解析失败本身是审查结论，不要在无法加载的文件上继续争论项序。
- 只把会改变表示的差异当作列表改动：条目增加或减少、条目次序调换、某条目在作为映射时键值发生变化、条目种类变化。这些都会改变表示图。
- 把下列差异降级为呈现或序列化细节：同一映射内键的书写顺序、块样式与 flow 样式互换但种类与内容相同、缩进宽度变化但从属关系不变、注释增删、标签句柄写法、处理器另选的锚点名。Dump 本就会引入这些细节。
- 专门查找看起来像改列表、其实改坏了结构的情况。漏短横线会让序列变成映射或触发重复键；多出来的短横线会把映射拆成序列。别名用星号引用先前用 & 标出的锚点，两处指向同一节点；只改其中一处呈现，审查时要顺着锚点看表示图，而不是只看被改的那一行文字。
- 判断依据：双方都能加载时，比较目标序列的有序内容是否一致。一致则列表未改；不一致则指出是哪一项的何种变化。不要用文件差异的行数衡量改动大小。
失败时下一步
无法加载时停止合并，回到可解析的版本。表示一致但文本冲突，按呈现差异处理，不必为映射键顺序争论。表示不一致时，按条目次序逐项确认，避免用 dump 得到的新文本覆盖对方注释——注释本来就不会进入构造。审查结论应写清是序列内容变化还是仅呈现变化，以免下一轮把样式差再次当成实质冲突。