如何检查网站死链：小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b2b2d7e0c1c8.html
📄
如何检查网站死链：小流量灰度如何暴露全量发布的例外
把灰度当成一次“抽样验证”，而不是最终结论：它能暴露全量发布时最容易被忽略的例外，但暴露不了所有例外。缺少完整日志或后台权限时，你仍可以用一份页面清单、一次小范围抓取和一次发布前后对比，得到足以决定“是否放量”的证据。
先明确灰度要回答的不是“有没有死链”，而是“例外在哪”
全量发布前，通常已经有一批链接被人工或工具确认可访问。真正危险的是那些只在特定条件下才变成死链的链接：只在某个参数组合下失效、只在某个地区或语言版本下失效、只在登录态或特定 UA 下失效、只在某个模板被复用时失效。灰度流量小，恰好适合把这些条件一个个挑出来。
假设一个页面模板包含三条外链和两条内链。全量抓取可能因为并发高、超时短而把慢响应误判为死链；小流量灰度反而能拿到更干净的响应码。反过来，灰度只覆盖少量 URL，如果它恰好都命中缓存，就无法证明源站没有断链。因此灰度的价值在于“发现例外”，不在于“证明全量无误”。
用一份页面清单把灰度结果转成可执行的处理方案
不要等完整日志。你手上通常已经有：一份待发布 URL 清单、一份旧站或旧版本的链接清单、一份模板文件。先把它们合并成一张表，字段至少包括：来源页面、目标 URL、链接位置（导航、正文、页脚、结构化数据）、是否站内、首次发现时间、灰度响应码、灰度响应时间。
然后按下面顺序处理：
- 先看 4xx 和 5xx 的分布。如果 404 集中在同一个模板或同一个目录前缀，说明是模板级问题，不是单条链接问题。下一步应检查该模板的链接生成逻辑，而不是逐条改链接。
- 再看 3xx 链的长度。单次跳转通常可接受；连续两次以上跳转在灰度中可能正常，在全量中会放大超时概率。下一步是把长链改成直接指向最终地址，或确认跳转是否故意保留。
- 最后看超时与 200 的边界。灰度中响应时间接近超时阈值的链接，在全量并发下更容易变成失败。下一步是给这类链接单独设更长的超时，或把它们从关键路径中移出。
做完这一步，你会得到两类结论：一类是“必须修”，一类是“可以带风险发布但需要监控”。这个区分直接决定下一步是回滚、修复还是扩大灰度比例。
一次小流量灰度能暴露什么，不能推出什么
灰度能暴露的例外通常有明确特征：
- 只在特定参数下返回 404 的链接，例如分页参数越界或筛选条件为空。
- 只在未登录状态下被重定向到登录页、而登录页又缺少返回路径的链接。
- 只在某个语言目录下缺失对应翻译页面的链接。
- 只在某个模板被复用时才出现的相对路径错误。
灰度不能推出的结论同样明确：
- 灰度中没有出现 404，不等于全量没有死链。未覆盖的 URL 仍然可能失效。
- 灰度中某个链接返回 200，不等于它在所有地区、所有设备上都可达。
- 灰度中抓取量或请求量归零，不能单独证明链接处理正确；它也可能是抓取被限制、页面未被发现或请求被合并的结果。
- 站点地图中列出了某个 URL，不保证它会被收录；
robots.txt的抓取限制也不等于可靠的索引移除。这些是不同层面的问题，不能互相替代。
缺少权限时，最小可执行动作是什么
如果你没有服务器日志、没有抓取后台、也没有发布系统的回滚权限，仍然可以做三件事：
- 用浏览器或命令行对灰度页面发起请求，只检查响应码和最终地址，不依赖任何平台界面。例如用
curl -I查看头部，确认状态码和Location字段。 - 把灰度页面中的链接与旧版本页面逐条对比，标记新增、删除和修改的链接。这一步不需要权限，只需要两份可访问的页面。
- 对标记出的链接做一次小范围复测，只覆盖灰度中异常和新增的链接，而不是全量重跑。
这些动作的结果会影响下一步：如果复测确认异常集中在新增链接，就先修新增部分再放量；如果异常分散且无法定位共同原因，就应缩小放量范围或暂停发布，而不是继续扩大灰度。灰度不是发布前的最后一道形式，它是用来决定“下一步该修什么”的证据来源。
把灰度结论写进发布决策，而不是写进检查清单
灰度结束后，不要只记录“发现 N 个死链”。要记录：哪些例外只在灰度条件下出现、哪些例外在全量条件下可能放大、哪些例外可以接受并监控。然后据此决定：是直接全量、先修后全量、还是扩大灰度比例再观察。
这个决定依赖的是例外与条件的对应关系，而不是死链总数。总数相同，分布不同，处理方式可能完全相反。灰度真正的价值，是让你在全量发布前就看到那些“只在特定条件下才成立”的例外，并把它们变成可执行、可验证、可回退的处理动作。
