www二级域名：一次小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1ed949b7e34a.html
📄
www二级域名：一次小流量灰度如何暴露全量发布的例外
把www二级域名切出一个小流量灰度，目的不是证明它“没问题”，而是提前找出全量发布时才会出现的例外。最值得警惕的信号是：灰度组表现正常，但未进入灰度的旧入口、缓存副本或跨域跳转却出现了不一致。此时不能直接全量，也不能因为灰度通过就忽略例外；正确动作是先把例外归因，再决定保留、改写还是退出这次发布。
灰度只覆盖新入口时，例外往往藏在旧入口
假设你准备把主站流量从裸域逐步迁到www二级域名，灰度只让一部分用户走新入口。灰度期间，新入口的响应、跳转和页面内容都正常，但监控之外仍有三类对象没有被覆盖：
- 已被缓存的裸域页面，仍可能返回旧版内容或旧版跳转。
- 外部链接、站内硬编码链接和站点地图里仍写着裸域地址。
- 带参数的落地页、分享链接和广告链接可能绕过灰度规则，直接命中旧入口。
这些对象在灰度中不出现，不代表它们不存在，只说明灰度样本没有覆盖到它们。判断依据不是灰度组是否正常，而是未进入灰度的入口是否仍产生与预期不符的结果。
保留、改写还是退出：三种取舍的适用前提
保留适用于例外只来自缓存或传播延迟，且核心入口、跳转关系和页面内容已经一致。此时可以继续扩大灰度，但要把旧入口的响应纳入同一观察范围，而不是只看新入口。
改写适用于例外来自配置本身，例如跳转规则只匹配了部分路径、站点地图仍输出裸域地址、部分链接没有随发布更新。改写的前提是能定位到具体规则或具体输出位置，而不是笼统地“再观察一段时间”。
退出适用于例外已经影响到核心访问路径，且无法在发布窗口内确认影响范围。退出不是失败，而是避免把灰度中未覆盖的例外带入全量。
三种取舍并不要求全部走一遍。缺少完整日志或权限时，仍可执行一个最小动作：从外部可访问的入口反向抽查。用不同来源的链接访问裸域和www二级域名，记录状态码、最终地址和页面标题是否一致。这个动作不能证明全量一定安全，但能暴露灰度没有覆盖到的入口差异。
一个假设例子：灰度通过，但旧链接仍指向裸域
假设发布计划是让www二级域名承接主站流量，灰度只对直接访问首页的用户生效。灰度期间首页正常，于是准备全量。随后抽查一条站内文章链接，发现它仍指向裸域，并且裸域返回的是旧版页面，而不是跳转到www二级域名。
这个结果说明灰度规则没有覆盖站内链接这一层。下一步不应直接全量，而应先确认链接是硬编码、模板输出还是重定向规则遗漏。如果是模板输出，改写模板并重新生成页面；如果是重定向规则遗漏，补充规则后再用同一批链接复查。复查结果只说明这批链接是否一致，不能推出所有入口都已一致。
看到异常后，哪些结论不能直接下
灰度中出现异常时，有几类推断需要避免：
- 某个入口返回异常，不等于全量发布一定失败，也不等于灰度方案本身无效。
- 某个入口返回正常，不等于其他入口也正常，尤其当灰度规则只匹配部分路径时。
- 抓取量或请求量下降，不能单独证明是www二级域名配置导致的，也可能是发布窗口、缓存刷新或外部链接变化引起的。
- robots.txt限制抓取不等于完成索引移除，站点地图提交也不保证收录；这两件事不能用来替代对实际入口的检查。
- HTTPS不保证页面没有其他问题，也不保证排名结果，不能把协议切换当作例外消失的证据。
不同搜索引擎对跳转和域名的处理需要分别核查，不能用一个平台的表现推断另一个平台。缺少完整数据时，能执行的最小动作是记录入口、状态码和最终地址，并把无法解释的差异列为待确认项，而不是直接归因为“灰度没问题”。
把灰度结论转成下一步动作
如果例外只出现在缓存副本，且核心入口一致，可以保留灰度并扩大样本，同时继续抽查旧入口。如果例外出现在跳转规则或链接输出，先改写对应位置，再用同一批入口复查。如果例外已经影响核心访问路径且无法确认范围，退出本次发布，保留现有入口，待规则明确后再重新灰度。
无论选择哪一种，下一步都应基于同一组可复核的入口记录，而不是基于灰度组是否好看。灰度通过只能说明被覆盖的部分通过，不能说明全量发布没有例外。
