有一次字幕回归测试突然把一串下游测试都带崩了。表面看，问题像是配置里出现了两个相同的字体和字号：解析器按这两个字段去找字幕样式，原本要求匹配结果必须恰好是 1 个，现在却找到了 2 个，于是直接失败。
我一开始也差点顺着这个表面去想：既然有 2 个，就给默认档案更高优先级；或者把其中一份档案的字体、字号改掉，让它们重新变成唯一匹配。这样的处理很快，却没有回答一个更重要的问题：这两个条目真的在描述同一件事吗？
后来把字段放回各自的语义里看，冲突才变得清楚。其中一个条目确实是字幕样式预设，另一个虽然也写着同样的字体和字号，却同时带有纵向位置参数。它不是另一个样式，而是一份布局档案。两份档案只是恰好共享了几个字段，并不代表它们属于同一个匹配空间。
配置发生碰撞时，先判断字段描述的是同一维度，还是不同对象恰好共享了部分值。
失败表面上是唯一性被打破
这次失败最容易让人盯住“唯一”两个字。解析器的规则很明确：按字体和字号匹配字幕样式，结果必须恰好为 1 个。0 个说明配置缺失，2 个则说明匹配条件不够精确。无论哪一种，都不应该让解析器默默猜一个。
所以，测试失败本身不是多余的阻碍。它及时指出了当前筛选条件与配置数据之间的矛盾。如果把唯一性校验删掉，或者改成“第一个能用就用”，这一次测试也许会恢复，但错误会被推迟到更难排查的位置。不同环境下的读取顺序可能不同，新增一份配置后结果也可能悄悄改变。字幕看起来能生成，并不等于使用了正确的配置。
如果不处理这个边界，后果不只是一个测试红了。依赖样式解析的回归会一起失败，后续的人会误以为字体配置损坏，接着去改更多档案；而真正负责位置的布局配置仍然在另一条链路里单独解析。两个问题被混在一起，修复范围就会越来越大。
这件事让我重新意识到，唯一性不是“最终随便选一个”的技术习惯，而是一种保护。它要求我们在数据模型没有说清楚之前停下来。真正要修的，往往不是这个保护，而是让它接收到正确的数据集合。
共享字段不等于共享身份
两个条目都写了相同的字体和字号，看起来当然像重复配置。但字段的值相同，只能说明它们在这两个维度上相同，不能证明它们的职责相同。一个条目回答“字幕文字用什么外观”，另一个条目回答“字幕对象放在什么位置”。它们都可能需要字体信息，却仍然属于不同的配置对象。
这里最容易误判的是把数据表当成平面列表。只要字段名相同，就把所有条目放进同一个候选集合，再期待调用方用默认值解决冲突。这样做实际上把建模责任推给了解析器。解析器既要猜对象类型，又要决定冲突时谁优先，最后自然会出现越来越多的例外规则。
我更愿意先问一句：这个解析器有权消费哪些数据？字幕样式解析器只需要样式档案；布局本来就通过另一份布局配置单独解析，因此带位置参数的条目不应该进入样式匹配。问题不是“两个候选如何排序”，而是“其中一个候选从一开始就不属于这里”。
解析器的可靠性，首先取决于它拿到的候选集合是否属于自己的语义边界。
这也是我没有直接修改默认优先级的原因。默认值可以处理缺省，却不能替代对象分类。让 default_profile 强行赢，只是给当前碰撞安排了一个赢家，下一次如果出现另一个布局字段、颜色字段或更多共享字段，仍然会继续猜。随意修改档案中的字体和字号也一样，只是改变了数据来迎合错误的匹配范围。
修复不是消灭碰撞，而是收窄边界
最终的修复很克制：在样式解析时，排除带纵向位置字段的条目，只让真正的样式预设参与匹配。这样，原来的唯一性硬门仍然保留。筛选完成后如果没有找到 1 个结果，解析器继续失败；如果意外找到多个，仍然继续失败。变化只有一个：布局档案不再冒充样式候选。
这个决定的关键不在于某个字段名字，而在于字段背后的职责。带位置参数的条目说明它包含布局信息，因此不应被只关心外观的解析器消费。未来如果布局档案新增其他位置或变换字段，仍然可以沿着同一个边界判断，而不必重新发明一套优先级。
我选择保留唯一匹配，是因为“只剩一个”必须来自正确的分类，而不是来自排序。如果筛选之后仍然有两个真正的样式预设，那就是配置建模仍有问题，应该继续暴露。把硬门保留下来，等于把未来的误配风险留在测试阶段，而不是让它变成用户看到的字幕差异。
这一步也改变了排查顺序。以前看到多个结果，可能先查调用顺序、默认值和读取顺序；现在会先检查候选条目是否混入了其他职责。顺序不是不能查，但它应该排在语义边界之后。否则，我们很容易用执行顺序掩盖数据模型的问题。
配置说明和测试要锁住同一个判断
只改解析器还不够。代码能够过滤这次已知的布局条目，却不一定能让后来维护配置的人理解为什么要过滤。于是配置层补充了说明，明确样式档案与布局档案的区分规则：样式负责文字外观，布局负责位置和变换；带位置信息的条目不参与样式匹配。
这类说明的价值，不是让文件看起来更完整，而是把一次排查得到的判断留下来。没有这句话，下一位维护者可能看到“字体和字号一样”，再次把条目合并，或者为了通过测试删掉一个看似重复的档案。说明把隐含知识变成了配置模型的一部分。
同时，回归测试放在配置层，而不是只测试解析函数返回了什么。测试保留了一个具体碰撞场景：样式预设与带位置参数的布局档案共享字体和字号。预期结果不是“默认档案胜出”，而是布局档案被排除后，样式解析仍然得到唯一结果。这样测到的就是边界，而不是某一次实现顺序。
好的回归测试不是把这次答案固定下来，而是把以后不能越过的语义边界固定下来。
这也解释了为什么相关回归测试通过之后，还要继续跑全量测试。局部测试证明碰撞规则被覆盖，全量测试则检查其他样式、布局和下游调用没有因为候选集合变化而被误伤。两种验证回答的是不同问题，不能用其中一个替代另一个。
从一次碰撞得到可复用的方法
这次经验可以整理成一套很小的流程。遇到配置碰撞时，先列出发生匹配的字段，再问每个字段在业务上代表什么。接着给候选条目标出职责：它是样式、布局，还是其他维度的数据。然后检查解析器应该消费哪些职责，只把属于自己的条目送入匹配。最后保留唯一性校验，并在配置层写一个能复现共享字段碰撞的回归测试。
这个方法看起来比改默认值慢一点，却能减少后续反复。因为它把“怎么选”提前转换成“哪些数据有资格被选”。当配置数量增加时，解析器不必知道所有档案的排序，也不必为每个例外增加一条特殊优先级。
如果要把它写成一条规则，我会这样记：先做语义过滤，再做值匹配；先确认候选资格，再讨论唯一性；发现多个结果时，先查是否混入了别的维度，最后才考虑排序。错误捷径往往让测试变绿，却不会让模型变清楚。
这件事让我重新意识到，配置不是一堆可以随手调数值的开关。字段之所以存在，是因为它们在描述对象。一个流程成熟的标志，不是它能在碰撞时猜对一次，而是它能让不该进入的候选根本进不来。
下次我会怎么做
下次遇到类似的解析失败，我会先把错误信息还原成数据问题：到底是没有候选、出现多个候选，还是候选集合混入了别的职责。我会逐个查看冲突条目的全部关键字段，不只比较报错里出现的字体和字号。尤其要留意位置、变换、时间或状态这类能说明对象身份的字段。
如果确认是不同维度共享了值，我会先收窄解析器的输入范围，再决定是否需要调整配置。不会先让默认档案强行获胜，也不会为了消除碰撞而任意改掉原本有意义的字段。唯一性校验会继续保留，因为它是提醒未来配置变化的最后一道门。
修复完成后，我会同时补两样东西：一段能让维护者看懂边界的配置说明，以及一个模拟真实碰撞的配置层测试。局部回归通过后，再跑全量测试，确认这个边界没有改变其他下游行为。
表面上，我是在处理字幕样式冲突；其实，我是在决定一个解析器应该相信什么。真正可靠的选择，不是从多个答案里猜出一个，而是先把不属于问题的答案排除出去，再让唯一性校验继续说真话。