死链检查，小流量灰度为何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /44d3252c3cc4.html
📄
死链检查，小流量灰度为何暴露全量发布的例外
灰度只覆盖少量入口时，死链检查结果往往“干净”；一旦全量发布，同样的规则却在长尾页面、旧链接和跨目录跳转上冒出大量例外。原因通常不是工具失灵，而是样本没有触达这些边界条件。要把灰度结论安全地推到全量，先得区分两种解释：样本偏差，还是规则本身存在未覆盖的分支。
两种解释：样本没碰到，还是规则没写全
第一种解释是样本偏差。灰度往往选的是主路径、高流量栏目或近期更新的页面，这些位置的链接维护最勤，返回状态也最稳定。全量发布后，真正被放大的是一批长期无人访问的归档页、分页尾部和历史跳转，它们平时不在监控范围内，自然在灰度里“看不见”。
第二种解释是规则缺陷。检查脚本可能只判断了顶层链接的返回码，没有跟进二次跳转；或者只处理了绝对路径，遇到相对路径和大小写差异就漏判。这种情况下，即使灰度样本扩大到全部页面，结果依旧会漏，因为问题出在判断逻辑，而不是覆盖范围。
两者的表现相似——全量后异常变多——但成因完全不同，对应动作也不同：前者要补抽样，后者要改规则。
能区分这两种解释的证据
关键证据是：把灰度里“通过”的那批链接，按页面类型、目录层级、链接深度重新分组，看异常是否集中在灰度未覆盖的组里。
- 如果异常几乎全部落在灰度没选的类型（如归档页、尾页分页），倾向样本偏差。
- 如果异常也出现在灰度选中的类型里，只是当时没报，倾向规则缺陷。
- 如果同一批链接在灰度时返回正常、全量时返回异常，且中间没有内容变更，要优先怀疑抓取限制、频次或超时导致的假阳性，而不是链接真的坏了。
这里有一个容易误判的点：某次检查里异常数量骤降甚至归零，不能单独证明修复正确。也可能是抓取被限流、脚本提前退出，或目标站点临时不可达。需要结合返回码分布和抓取日志一起看，才能判断是“真修好了”还是“没抓到”。
一个注明假设的短例子
假设某站点有 2000 个页面，灰度只抽了首页、栏目页和最近更新的 50 篇文章，死链检查全部通过。全量发布后，脚本报告 300 个异常链接，其中 280 个集中在三年前的文章归档里。
此时先不要急着批量改链接。按上面的分组方法，把 280 个异常按目录和链接深度拆开：如果它们全部落在灰度未覆盖的归档目录，且返回码以 404 为主，说明是样本偏差，下一步是扩大抽样范围，把归档页纳入常规检查；如果其中一部分出现在灰度已覆盖的栏目页，且返回码杂乱（404、超时、跳转循环混在一起），说明规则或抓取方式有缺陷，下一步应先修判断逻辑，再谈批量修复。
这个例子的数字只用于说明比较方法，不代表任何真实站点的规模。
灰度结论推到全量前，先确认适用边界
灰度成立不等于全量成立，边界主要在三处：
- 页面类型边界：灰度选中的类型和全量实际存在的类型是否一致。归档页、标签页、搜索结果页往往有独立的链接结构。
- 链接深度边界：灰度是否覆盖了深层跳转。只检查首层链接，无法发现二次、三次跳转中的断点。
- 抓取条件边界：灰度时抓取量小、间隔宽松，全量时频次提高，可能触发目标站点的限流，产生与真实死链无关的异常。
另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。灰度里“能抓到、能返回”只说明抓取层面没问题，不能直接推出索引层面的结论。不同搜索引擎对同一批链接的处理也可能不同，需要分别核查，而不是拿一个引擎的结果套用到全部。
把灰度变成可推全量的检查动作
要让灰度结论真正支撑全量决策，可以按这个顺序做：
- 先按页面类型和目录层级分层抽样，而不是只挑高流量入口。
- 对每个样本记录返回码、跳转链和抓取时间，形成可复查的证据，而不是只记“通过/失败”。
- 全量发布后，把新出现的异常按“灰度已覆盖/未覆盖”两类归因，再决定是补抽样还是改规则。
这样做的结果是：下一步动作有了明确依据——样本偏差就扩大覆盖范围，规则缺陷就回到脚本修正，而不是在全量异常面前一次性批量改链接，把真正的问题掩盖过去。
