永久重定向方法：小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d3da7bc0165a.html
📄
永久重定向方法：小流量灰度如何暴露全量发布的例外
小流量灰度只验证了“大多数请求走通”，全量发布却会撞上灰度流量根本覆盖不到的例外：带查询参数的旧链接、被外部系统直接调用的接口路径、以及只在内网或特定 UA 下出现的入口。灰度的价值不是证明方案正确，而是用低成本把例外挤到台面上；如果你把它当成放量前的确认仪式，例外就会在全量时一次性爆发。
为什么灰度通过、全量仍然出错
常见的矛盾现象是：灰度阶段监控显示跳转成功率接近理想值，放量后错误日志突然增多。这通常有两种解释，需要用不同证据区分。
解释一：流量结构差异。灰度只切了某类入口（比如首页或新导航），而全量会引入搜索引擎爬虫、老客户端、第三方回调和书签直达。这些流量携带的路径形态和参数与灰度样本不同，规则没覆盖到。
解释二：规则叠加顺序问题。灰度环境里规则数量少，全量后多条重定向规则、CDN 层规则和源站规则同时生效，匹配优先级发生变化，部分请求被错误规则先截获。
用哪些证据区分这两种解释
不要只看总体成功率，要按维度拆开看：
- 按入口来源拆分：直接访问、站内跳转、外部引用、爬虫抓取分别统计命中情况。如果错误集中在某一来源，偏向解释一。
- 按路径形态拆分：无参数、带查询串、带尾部斜杠、大小写变体分别核对。如果只有特定形态失败，偏向解释一。
- 按规则命中链路拆分：记录每个请求实际命中的是哪条规则，而不是只看最终状态码。如果同一路径在灰度和全量命中不同规则，偏向解释二。
一个可执行的动作是：在灰度阶段就打开规则命中日志，而不是只统计 301 数量。这样放量后你能对比同一路径的命中差异，直接定位是覆盖不足还是顺序错乱。这一步的结果决定下一步——覆盖不足就补规则，顺序错乱就调整优先级，两者的修复动作完全不同。
哪些例外在灰度里天然测不到
灰度样本通常来自你控制的入口，而以下请求往往绕开灰度：
- 外部合作方硬编码的旧接口地址，它们不会跟随你的导航更新。
- 搜索引擎已收录的带参数 URL，抓取时机不受你控制。
- 移动端旧版本客户端内置的跳转逻辑。
- 邮件、文档、二维码里长期存在的直达链接。
这些例外的共同点是：请求发起方不在你的灰度分流范围内。因此灰度覆盖率再高，也不能替代对“谁还在调用旧地址”的排查。
假设例子：一次带参数链接的放量失败
假设某站点把旧栏目整体重定向到新栏目，灰度只测了无参数的栏目首页，全部通过。全量后，带 ?page=2 这类分页参数的旧链接返回 404，因为规则只匹配了精确路径，没有处理查询串。
这不是灰度“没测准”，而是灰度样本里根本没有带参数的请求。能暴露它的动作是：在灰度阶段主动构造一批带参数、带斜杠、带大小写变体的请求，观察规则是否按预期命中。如果这批请求在灰度就失败，你会在放量前补上参数透传规则；如果灰度通过而全量失败，说明真正的例外来自灰度覆盖不到的外部调用方，需要转向排查外部依赖。
放量前应该确认的适用条件
灰度能否代表全量，取决于三个条件是否成立：
- 灰度流量与全量流量在入口来源上是否同分布。
- 灰度环境与正式环境的规则集是否一致，包括 CDN、网关和源站各层。
- 是否存在你无法分流的调用方（外部系统、旧客户端、已收录链接）。
只要第三项为真，灰度就不能作为全量安全的充分证据。此时更稳妥的做法是分批放量并保留快速回退能力，而不是一次性切换。另外注意，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这些手段都不能替代对重定向规则本身的验证。
把灰度定位成“例外探测器”而不是“正确性证明”，你才会在放量前主动去找那些测不到的请求，而不是等它们在线上替你找到。
