死链接检测，小流量灰度为何暴露了全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6104b6a76f5d.html
📄
死链接检测，小流量灰度为何暴露了全量发布的例外
答案取决于你检测的是“链接本身”还是“发布链路”：灰度只覆盖部分入口时，死链接检测可能全部通过；一旦全量发布，未被灰度触达的模板、重定向规则或旧路径才返回404，于是例外出现在最不该出现的地方。下面用一个明确假设的情境，把判断与动作拆开。
假设情境：灰度通过，全量却冒出404
假设某站点改版商品分类页，先对约5%的流量开放新路径，其余仍走旧模板。灰度期间，你抓取新路径下的内链，状态码正常，于是判断可以全量。全量后，旧模板里残留的“相关分类”链接被替换成新路径，但其中一部分指向了只在灰度环境存在的参数组合，返回404。这个结果与直觉相反：检测本身没问题，问题在于灰度样本没有覆盖旧模板的链接生成逻辑。
这里的关键不是“再检测一次”，而是先确认灰度覆盖的入口集合是否等于全量入口集合。若不等，灰度通过就不能推出全量通过。
先区分三种“死”的成因
- 目标资源真的不存在：链接指向的路径已被删除，且没有对应重定向。这类在灰度与全量中表现一致。
- 发布链路差异：链接由模板、参数或环境变量拼出，灰度环境与生产环境取值不同。这类只在全量后出现。
- 中间层拦截：CDN、网关或权限规则对未登录、未命中缓存的请求返回404或403。灰度流量少、缓存命中高时容易被掩盖。
把这三类分开，才能决定下一步是补重定向、改模板，还是查中间层。若只看到“404数量上升”就统一加跳转，可能把第二类问题掩盖成第三类问题。
用可核对的证据缩小范围
先取一组全量后返回404的URL，逐条记录：请求时的Referer、User-Agent、是否带参数、响应头中的缓存与服务器标识。然后做三个对照：
- 把同一URL去掉参数再请求，若恢复正常，说明问题在参数生成逻辑，而非资源缺失。
- 用灰度期间相同的请求头重放，若结果不同，说明差异来自请求上下文而非链接本身。
- 在旧模板与新模板各取一个页面，分别抓取其内链集合，比较差集。差集中的链接就是灰度未覆盖的部分。
这些动作的结果会直接改变下一步：若差集集中在旧模板，优先修模板；若集中在参数，优先修生成规则；若只在特定请求头下出现，优先查中间层。
灰度设计上要补的一个检查
死链接检测在灰度阶段常只验证“新路径可达”，却漏掉“旧入口是否仍被引用”。一个可操作的补充是：在灰度期间，除了抓新路径，也抓取仍走旧模板的页面，把两者的出链合并去重后再检测。这样做的结果是，灰度样本从“新功能样本”变成“发布影响面样本”，全量后的例外会明显减少。
需要说明的是，站点地图不保证收录，robots.txt的抓取限制也不等于可靠的索引移除；这些与死链接检测的发布判断不是同一层问题，不能用来替代对链接生成逻辑的核对。
决策规则：什么条件下可以全量
可以全量的条件不是“灰度零404”，而是：灰度覆盖的入口集合与全量入口集合一致，且旧模板的出链已纳入检测。若两者不一致，即使灰度结果全绿，也应先补齐覆盖再发布。反过来，如果全量后出现的404集中在灰度未覆盖的旧模板，那么回退全量未必是最优解，先修模板并只对差集做定向检测，通常比整体回退更可控。
这套判断依赖一个前提：你能拿到灰度与全量的入口清单并做差集。若拿不到，任何“检测通过”都只是局部结论，不能当作全量发布的通行证。
