二级域名设置灰度只放小流量，为什么全量发布才暴露例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fc26ebde5156.html
📄
二级域名设置灰度只放小流量，为什么全量发布才暴露例外
因为灰度往往只覆盖“主路径”和“干净样本”，而全量发布会把旧链接、旧系统回调、历史合作方流量一起放进来。例外通常不在新代码里，而在这些被灰度忽略的入口上。判断该不该继续全量，关键不是灰度有没有报错，而是灰度样本是否包含全量后必然出现的旧入口。
先分清灰度测的是新路径还是老入口
假设一个场景：某站点把帮助中心从主站迁到 help.example.com，二级域名设置完成后，灰度只让 5% 的新访客走新域名，老访客仍走旧路径。灰度期间没有异常，于是直接全量切换。全量后才发现，旧版 App 的内置链接、合作方收藏的旧地址、以及部分历史页面的绝对路径，仍然指向原位置。这些流量在灰度里根本没被抽中。
所以第一步不是看灰度错误率，而是列出全量后会出现、灰度里不会出现的入口：
- 旧客户端或旧版本页面里的硬编码链接；
- 合作方、第三方系统保存的回调地址或跳转地址；
- 历史内容中写死的绝对路径；
- 外部站点或用户书签保存的旧地址。
如果灰度只按新访客比例放量，这些入口就不在样本里，灰度通过不能证明全量安全。
用一份入口清单决定灰度样本怎么切
灰度样本应该按入口来源切，而不是只按用户比例切。可以先把上面的入口列成清单，再给每一类分配可观测的最小流量，观察它在新二级域名下的响应。动作是：把旧客户端请求、合作方回调、历史绝对路径各抽一小部分导入新域名，记录返回状态和最终落点。结果是，如果某一类入口出现 404、跳转到错误页面或回调失败，就说明全量前必须先补映射或保留旧路径，而不是继续放大比例。
这里要区分两种成立条件：如果旧入口已经确认全部下线，灰度可以只测新路径；如果旧入口仍会持续产生流量，灰度必须包含它们，否则全量只是把未知风险一次性放大。
抓取限制和收录状态不能当作迁移完成的证据
全量后常有人用 robots.txt 或站点地图判断迁移是否成功。需要明确：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。旧二级域名即使被 robots 限制抓取，旧 URL 仍可能留在索引里；新二级域名提交了站点地图，也不代表旧入口的流量会立刻转移。
更可靠的观察是看旧入口的实际请求是否还在到达、到达后落到哪里。如果请求量下降，也不能单独证明处理正确，它还可能来自缓存过期、外部链接自然衰减或统计口径变化。把请求日志、跳转链路和入口清单对照，才能判断例外是消失了，还是只是暂时没被抽到。
假设例：一次全量后回调失败的排查顺序
假设全量后合作方反馈回调失败。排查顺序可以是：先确认合作方保存的是旧二级域名还是新二级域名；再确认该地址是否在灰度入口清单里；最后确认旧地址是否保留了可达的跳转或转发。动作是逐项核对，而不是先改 DNS。结果是，如果问题出在合作方保存的旧地址，补一条旧地址到新地址的映射就能解决；如果问题出在新域名本身不可达，才需要检查解析和证书。两种情况影响下一步：前者要继续保留旧入口一段时间，后者要暂停全量并回退。
全量前该保留什么、退出什么
旧内容、旧系统或旧合作关系需要退出时，不必一刀切。可以保留仍然有价值的部分，例如仍被外部引用的旧路径、仍在服务的合作方回调地址；退出已经确认无流量的旧页面。判断依据是入口清单里的实际请求，而不是主观猜测。全量发布前，至少让灰度覆盖每一类仍会产生流量的旧入口；全量后，继续监测这些入口的请求和落点，直到确认它们不再产生有效流量，再考虑关闭旧路径。
