死链检测：小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /66ea08b90b51.html
📄
死链检测：小流量灰度如何暴露全量发布的例外
灰度发布只放出少量入口，仍可能因为链接生成逻辑、重定向规则或缓存层差异，在全量流量下出现灰度里没见过的死链。灰度能帮你缩小排查范围，但不能直接证明全量发布安全——它更像一次受控抽样，例外往往藏在样本没覆盖到的路径里。
先明确灰度到底覆盖了什么
假设一个内容站要把旧栏目迁移到新目录，计划先让 5% 的详情页走新模板，其余保持旧模板。灰度期间只检查首页和栏目页，没有覆盖详情页之间的互链。灰度上线后首页正常，就认为全量发布没问题。
这里的问题不是灰度机制本身，而是样本边界：灰度放出的入口类型，和全量发布后用户实际会走的路径不一致。死链检测在这个阶段要回答的不是“有没有报错”，而是“哪些链接类型还没被灰度触达”。
可执行的最小动作：在灰度流量里，把访问日志按链接来源分组，列出灰度期间被请求过的链接类型，再对照全量发布后预计会出现的链接类型。如果灰度只覆盖了导航链接，而全量会新增正文内链和分页链接，那么灰度结果就不能外推到全量。
灰度正常但全量出现死链的常见原因
灰度与全量之间的差异，通常来自以下几类，而不是随机故障：
- 链接生成条件不同：灰度只对部分内容启用新模板，模板里拼接 URL 的字段在其余内容上可能为空或格式不同。
- 重定向规则未同步：旧链接到新链接的跳转，可能只在灰度涉及的目录上配置，全量目录仍返回 404。
- 缓存层差异：灰度请求量小，可能绕过某些缓存；全量后缓存键变化，导致旧缓存里的失效链接被重新暴露。
- 分页与筛选参数：灰度往往只测第一页，全量后带参数的分页链接更容易出现空结果或错误状态码。
这些原因的共同点是：灰度样本没有覆盖到触发条件。检测时如果只统计状态码数量，而不区分链接来源和参数模式，就会把“灰度没测到”误判为“全量后突然坏了”。
缺少完整数据或权限时，仍可执行的最小动作
如果你拿不到全量日志，也没有权限改服务器配置，仍然可以做两件事：
- 用灰度期间实际返回 200 的页面作为种子，抽取其中的站内链接，按链接模板归类，而不是逐条检查。
- 对每一类链接模板，构造一个假设的全量条件（例如把目录名替换为未灰度目录），用一次请求验证返回状态。这一步不依赖全量日志，只依赖你能访问的页面。
执行后，你会得到一张“链接模板—灰度是否覆盖—假设全量状态”的对照。它能告诉你哪些模板需要优先在全量前补测，但不能告诉你全量发布后一定没有死链，因为模板之外还可能有手工写入的链接。
哪些结论不能从灰度结果直接推出
灰度没有报死链，不等于全量发布后死链为零。以下推断都不成立：
- 灰度期间抓取量正常，所以全量后抓取量也会正常——抓取量受入口数量、站点地图和外部链接影响，灰度样本不包含这些变化。
- 灰度页面返回 200，所以同一模板在全量目录下也返回 200——模板变量、权限和重定向规则都可能不同。
- 站点地图里没有列出某个 URL，所以它不会被发现——站点地图不保证收录，也不限制其他入口的发现。
- 用 robots.txt 屏蔽了某个路径，所以它不会出现在索引里——抓取限制不等于可靠的索引移除，已收录 URL 仍可能保留。
这些现象还有别的合理解释：抓取量下降可能来自服务器响应变慢，也可能来自入口减少；某个 URL 未收录可能来自内容质量判断，而不只是链接状态。把单一指标归零当作处理正确的证据，容易漏掉真正的例外。
把灰度结论转化为全量前的检查项
假设前面的迁移场景中，灰度只覆盖了栏目页。你按链接模板归类后发现，正文内链和分页链接未被灰度覆盖，于是全量前对这两类模板各抽一个未灰度目录的 URL 做请求。结果发现分页链接在未灰度目录下返回 404，而正文内链正常。
这个结果影响下一步：你不需要停止全量发布，但需要在发布前修复分页 URL 的生成规则，并把灰度范围扩展到包含分页的页面类型。修复后再次用同一模板抽样验证，确认返回状态变化，再决定是否扩大灰度比例。
如果抽样后两类模板都正常，也不能直接宣布全量无死链。此时可行的下一步是把灰度比例提高，并让灰度覆盖所有链接模板各至少一个实例；仍然无法覆盖手工链接和外部导入链接，这部分只能在全量发布后通过持续监测发现。
死链检测在灰度阶段的价值，不是给出一个通过或不通过的结论，而是把“哪些例外还没被样本触达”变成一张可执行的补测清单。灰度能暴露例外，前提是你先承认样本边界在哪里。
