死链检查方法：小流量灰度为何会漏掉全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1997a4f683e2.html
📄
死链检查方法：小流量灰度为何会漏掉全量发布的例外
小流量灰度只能证明“被抽到的那部分请求没问题”，不能证明全量发布后所有入口都没问题。死链检查方法在灰度阶段最容易漏掉的，是低频入口、参数变体和外部引用路径。它们在小样本里几乎不出现，全量后却可能集中暴露。要判断一次灰度是否足以放行，关键不是看灰度有没有报错，而是看检查覆盖是否触达了这些例外。
先区分灰度漏报的三种可能原因
灰度结果正常、全量后出现死链，不一定是灰度本身失效。可区分的原因至少有三类：
- 样本偏差：灰度只覆盖高流量页面，低频但重要的入口没被访问到。
- 路径差异：灰度环境与全量环境在重写规则、参数处理或跳转链路上不同。
- 引用滞后：全量发布后，旧链接被外部页面、缓存或历史内容重新触发。
这三类的证据不同。样本偏差表现为灰度日志里根本没有某批 URL 的请求记录；路径差异表现为同一 URL 在两个环境返回不同状态码；引用滞后表现为灰度期间无请求、全量后突然出现来自站外或旧页面的访问。把现象归到错误的那一类，后续动作就会做偏。
用一个假设情境走完判断过程
假设某站点把栏目页从 /old-list/ 迁到 /new-list/，灰度只放量 5%，观察两小时后状态码全部为 200，于是决定全量。全量当天，监控发现一批 404 集中在带分页参数的旧地址，例如 /old-list/?page=3。灰度期间这些地址没有被请求过，因为灰度样本恰好只落在第一页。
此时的正确动作不是立刻回退，而是先做一次定向核查：把旧栏目所有分页、筛选参数和排序参数拼成候选清单，逐个请求并记录状态码与最终跳转目标。假设核查发现第一页做了 301，后续分页没有对应规则，那么问题定位为路径差异，而非样本偏差。下一步应是补齐分页映射规则，再对同一批候选清单复测。复测通过后，才考虑继续放量。这个顺序的价值在于：先确认例外集合，再决定是修规则还是回退，避免用回退掩盖一个本可局部修复的映射缺口。
把灰度检查从“看状态码”改成“对清单”
要让灰度暴露全量例外，检查对象不能只是灰度期间产生的访问日志，而应是一份提前构造的 URL 清单。清单来源可以包括：
- 站点地图中声明的地址，用于核对是否可达；但站点地图不保证收录，也不等于全量入口。
- 站内链接抓取结果，覆盖导航、分页、筛选等模板化路径。
- 历史访问日志中去重后的旧地址，尤其是带参数的变体。
- 外部引用中指向本站的地址，用于发现站外仍在使用旧路径的情况。
对清单逐项请求，记录状态码、跳转链和最终落地地址。这样做的结果不是“确认没有死链”，而是得到一份例外集合。例外集合的大小和分布，直接决定灰度能否放行：如果例外集中在少数模板，修模板即可；如果例外分散且无规律，说明迁移规则本身不完整，放量风险更高。
几个容易误判的信号
灰度期间没有 404，不等于全量后没有死链。没有请求记录和请求成功是两回事，前者说明样本没覆盖，后者才说明路径可用。同理，日志中 404 数量归零也不能单独证明处理正确，可能只是流量下降、抓取减少或监控口径变化。
还要注意：robots.txt 的抓取限制不等于可靠的索引移除，被限制抓取的地址仍可能以其他方式出现在结果中；HTTPS 也不保证页面不存在链接断裂或跳转错误。这些都不替代逐项核查清单。
如果站点同时依赖搜索引擎、平台推荐和广告落地页，三者的入口集合并不相同。灰度清单应分别覆盖，不能只用其中一类的日志代表全部。不同搜索引擎对跳转和参数的处理也有差异，需要分别核查，不能以一次结果推断所有渠道。
放行前需要满足的条件
一次灰度要支撑全量发布，至少应满足：候选清单已覆盖主要模板和已知旧地址；清单中每一项都完成了状态码与跳转链核查；例外集合已分类并明确处理方式；处理后的规则在同一清单上复测通过。缺少任何一项，灰度结果都只能说明被抽到的部分可用，不能说明全量发布不会产生新的死链。把这些条件写成可核对的记录，比依赖“灰度没报错”更接近可放行的判断依据。
