域名注册记录：小流量灰度暴露全量例外时，保留、改写还是退出
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0705f73b4473.html
📄
域名注册记录：小流量灰度暴露全量例外时，保留、改写还是退出
小流量灰度里域名注册记录看起来一切正常，全量发布后却出现例外，通常不是灰度本身失效，而是灰度样本没有覆盖全量流量的某些条件。此时先不要急着回滚或改规则，而应判断例外是注册记录本身的问题，还是灰度样本与全量之间的条件差异。保留、改写、退出三种取舍，分别对应不同的前提。
先确认例外来自哪一类条件差异
灰度与全量之间常见的差异有几类：一是样本量变大后，原本占比极低的分支被放大；二是灰度只覆盖部分入口，全量后新增入口带来不同的请求形态；三是灰度期间人工干预较多，全量后干预撤掉，真实行为才显现。判断方法不是看总体成功率，而是看例外是否集中在某个入口、某个时段或某种请求参数上。
如果例外只出现在灰度未覆盖的入口，说明问题在覆盖范围，不在规则本身；如果例外在灰度覆盖的入口也存在，只是量小到没被注意，说明问题在样本量。这两种原因的后续动作完全不同：前者要补覆盖，后者要补样本。
保留：例外可归因且影响可控时
保留的前提是例外有明确归因，且影响范围可以被描述清楚。例如灰度期间只验证了主流程，全量后发现某个次要分支的注册记录写入顺序与预期不同，但这个分支本身流量占比很低，且不触发下游依赖。此时保留现行方案、单独记录该分支，比整体回滚更省成本。
保留不等于忽略。需要做的实际动作是：把例外分支单独打标，观察它在下一轮全量中的表现是否稳定。如果连续观察后例外不再扩大，保留成立；如果例外随流量线性增长，说明它只是被样本量掩盖，保留的前提已经不成立。
改写：例外由规则边界引起时
当例外集中在规则边界附近，比如某个字段长度、某个时间窗口、某种编码形式，改写规则比退出更合适。改写的关键是只动边界，不动主体逻辑。例如把原本假设固定的字段改为可配置，或把单一判断条件拆成两个条件，让原本被误判的样本走另一条路径。
改写后需要重新做一次小流量验证，但验证目标要变：不是验证整体是否正常，而是验证原来出例外的那批样本是否被正确分流。如果改写后例外消失但主流程出现新偏差，说明改写动到了不该动的地方，应退回保留状态再评估。
退出：例外不可归因或代价不可接受时
退出的前提是例外无法在合理时间内归因，或归因后修复代价高于收益。例如例外分散在多个不相关分支，没有共同特征，继续排查会拖长发布周期。此时退出不是失败，而是把不确定性控制在已知范围内。
退出后要做的不是直接放弃，而是保留灰度阶段的记录，把例外样本单独存档，等下一次有更合适的验证条件时再处理。退出的代价是发布进度延后，收益是避免把未知例外带入全量。
一个假设例子：如何用假设检验取舍
假设灰度覆盖了 5% 的请求，全量后例外比例从灰度的 0.1% 升到 1%。如果例外集中在灰度未覆盖的入口，说明覆盖不足，应补覆盖后重测；如果例外在灰度覆盖的入口也存在，只是当时样本太少没触发，说明是样本量问题，应扩大灰度比例而不是改规则。这个例子里的数字只用于说明比较方法，不代表任何真实项目的表现。
取舍的判断顺序建议是：先确认例外是否可归因，再确认影响是否可控，最后确认修复代价是否低于退出代价。三步都通过才考虑保留，任一步不通过就转向改写或退出。
边界：哪些结论不能直接照搬
小流量灰度成立的结论，不能直接套到全量，因为灰度天然过滤掉了低频分支和长尾入口。同样，一次全量出现的例外，也不能直接证明灰度方法无效，它可能只是暴露了灰度设计的覆盖缺口。域名注册记录相关的判断尤其要注意：注册记录的变化往往滞后于请求变化，灰度期间看到的正常，可能只是记录尚未更新，而不是真的没有问题。
另外，抓取限制、站点地图提交或启用 HTTPS 都不能替代对例外本身的归因，它们各自解决的是不同层面的问题。把例外归因清楚，再决定保留、改写还是退出，才是可复用的处理路径。
