404错误修复：小流量灰度怎样暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dfdec3727d56.html
📄
404错误修复：小流量灰度怎样暴露全量发布的例外
灰度只覆盖了主站路径时，全量发布后最先暴露的往往不是规则本身，而是被排除在灰度外的例外：带参数的历史外链、旧目录的尾斜杠写法、分站或子域里复制的同一路径。修复404的关键不是再补一条通配规则，而是先用灰度确认哪些请求形态没被采样到，再决定是扩大映射范围还是保留404。
先判断例外属于哪一类：路径形态，还是来源形态
两种条件的处理选择完全不同，先分类再动手。
- 路径形态例外：同一内容存在多种写法，如
/old-page、/old-page/、/old-page?utm_source=x。这类例外的证据是服务器日志里同一路径族反复出现404，且去掉参数或补上尾斜杠后能命中200。处理动作是让重定向规则在匹配时忽略查询串并同时接受带不带尾斜杠，而不是为每个参数值各写一条。 - 来源形态例外：404集中在某个子域、某个语言目录或某批外链指向的旧路径上，主域灰度根本没经过这些入口。证据是404的Referer或Host字段高度集中在灰度未覆盖的范围。这类情况不能靠扩通配解决，需要判断该来源是否仍应存在：仍要保留就补对应映射，已废弃就让它维持404并确认没有站内链接指向它。
如果两类混在一起，先按Host和路径前缀拆分日志再统计，否则会把来源问题误当成规则问题，越修越乱。
灰度样本要能代表例外，否则全量必然漏
常见做法是挑几个访问量高的URL做灰度，结果全量后低流量但外链密集的旧路径集体404。要让灰度有代表性，抽样应覆盖维度而不是覆盖流量：
- 按路径深度抽样，至少包含一级目录和三级以上深层路径各若干。
- 按URL写法抽样，带参数、带尾斜杠、大小写混写各取样本。
- 按Host抽样，主域之外若有子域或镜像目录，各取一条。
灰度期间观察的是这些样本返回的状态码和最终落点，而不是总404数量。数量下降可能只是因为灰度流量小，不能作为规则正确的证据。
一个假设例子：灰度通过、全量仍报错
假设某站把 /product/123 迁到 /items/123，灰度只测了主域下10条深层路径，全部301成功。全量后发现旧版移动子域 m.example.com/product/123 仍返回404，因为重定向规则写在了主域配置里，子域没有继承。
此时有两种选择：
- 如果子域仍在对外提供访问，就在子域配置里复制同一套映射，并单独灰度验证，因为两个配置的匹配顺序可能不同。
- 如果子域已停用，正确动作是让子域整体返回410或统一跳主域，而不是逐条补
/product/映射。逐条补会掩盖子域已废弃这一事实，后续还会不断冒出新404。
判断依据是子域是否还有有效入口和流量。有流量就补映射，没流量就整体处理，两者不能混用。
修复动作之后，用状态证据决定下一步
改完规则先别急着宣布完成，取一轮可复查的证据：对灰度样本和全量日志中各取一组URL，记录请求URL、返回状态码、最终落点。如果出现以下现象，说明还有例外没处理：
- 同一路径带参数时命中200，不带参数时仍404，说明规则对查询串的处理不一致。
- 301链条超过一跳，说明新旧规则叠加，需要合并而不是继续追加。
- 某来源的404在修复后归零，但该来源整体请求量也归零，这不能证明修复正确，可能只是该入口已无流量，需要另找证据确认。
另外要区分抓取限制与索引移除：robots.txt 里禁止抓取某路径，并不会让已存在的404页面从索引中消失，也不能替代正确的重定向或410处理。站点地图里列出的URL返回404，只说明地图与实际状态不一致，不代表搜索引擎一定会按地图处理。修复后是否被重新抓取和替换索引结果，仍需按各搜索引擎的实际情况分别核查，不能用一个平台的表现推断另一个。
当灰度样本、全量日志和来源分布三者一致时，才把这次修复视为闭环；只要还有一类来源没被采样覆盖，就先补采样再改规则，否则下一次全量发布还会在同一个例外上重复出错。
