📍 WDQWDWQD987AAAAA:23.251.146.115
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ShapBot/0.1.0
🔗 /e30904db49c8.html
📄

网站死链检查：小流量灰度如何暴露全量发布的例外

小流量灰度能暴露全量发布中容易被掩盖的例外，前提是灰度样本覆盖了产生死链的关键路径，并且你记录了状态码、跳转链和来源页。做不到这两点，灰度通过并不能推出全量发布不会出现死链；它只能说明被抽到的那部分请求在当次检查中没暴露问题。

灰度真正能暴露的是路径差异，不是“数量少所以安全”

全量发布时，死链往往不是均匀分布的。它更常集中在少数入口：某个栏目模板、某批旧链接、某条重写规则、某个只在特定参数下才走到的跳转分支。灰度如果只抽首页和少量详情页，这些分支可能一次都没被触发，结果是灰度全绿、全量上线后才由日志或用户反馈暴露。

因此判断灰度是否有价值，不看它跑了多少请求，而看它是否走到以下位置：

• 被删除或改名的旧路径，以及指向它们的站内链接；
• 会做 301 或 302 跳转的规则，尤其是多级跳转；
• 分页、筛选、参数化 URL 等容易生成变体的入口；
• 由脚本或模板批量生成的链接，而不是编辑手工维护的链接。

如果灰度请求全部落在稳定入口，那么它没有覆盖死链的高发区，结论不能外推到全量。

一个反例会让“灰度通过”立刻失效

反例：灰度环境与生产环境的路由或重写规则不一致。假设灰度只把新版本应用接入，但反向代理、CDN 缓存规则或 URL 重写仍沿用旧配置。此时灰度里访问旧路径可能返回 200，因为旧规则还在生效；全量切换后规则同步更新，同一路径才变成 404。灰度结果不但不能证明安全，反而会给出错误的安全感。

类似地，如果灰度流量被缓存层拦截、被 robots 规则挡在抓取之外，或者只走内网 DNS，那么你观察到的响应并不代表外部访问者会遇到的响应。要区分这些原因，可以对照同一路径在灰度与全量候选环境下的响应头、跳转目标和最终状态码，而不是只看“是否有报错”。

缺少完整数据和权限时，仍可执行的最小动作

没有全站日志、没有搜索平台权限、没有抓取配额时，仍然可以做一件具体的事：选取一批已知会变更的 URL，在灰度环境逐条请求，记录状态码、跳转链和最终落地页，并与变更前的记录对照。

动作与结果的关系可以这样理解：

1. 先列出本次发布中“被改动”的路径，而不是随机抽样。
2. 对每条路径请求一次，记录 状态码、Location 头和最终 URL。
3. 若某条路径在灰度返回 200 但最终 URL 与预期不符，说明跳转规则有问题，下一步应检查重写配置，而不是继续扩大灰度流量。
4. 若某条路径在灰度返回 404，先确认它是否本就应被移除；若不应移除，下一步是修规则后再重跑同一批路径。

这个动作的结论边界很明确：它能发现“被改动路径”上的例外，不能证明未被抽到的路径没有问题，也不能替代全量发布后的持续观察。它适合在权限受限时作为发布前的一次定点验证。

灰度结果不能推出的几件事

灰度通过不等于全量安全，也不等于搜索引擎会按你的预期处理这些 URL。需要分别核查的点包括：

• robots.txt 的抓取限制只约束抓取行为，不等于可靠的索引移除；被挡住的 URL 仍可能以其他方式出现在结果中。
• 站点地图提交不保证收录，它只是提供发现线索。
• HTTPS 不保证页面没有漏洞，也不保证排名；它只是传输层的一个条件。
• 不同搜索引擎对跳转、状态码和索引处理的反应需要分别核查，不能用一个引擎的表现推断另一个。

此外，如果灰度期间抓取量或请求量降到零，这不能单独证明处理正确。它也可能是缓存命中、流量本身下降、监控口径变化或抓取被限制造成的，需要结合响应记录判断。

下一步：把灰度结论转成可复查的发布检查

如果灰度覆盖了变更路径且环境一致，下一步是把这批路径固化成发布后的复查清单，在全量上线后按同一方法重跑一次，比较状态码与最终 URL 是否一致。如果灰度没有覆盖变更路径，或环境与生产不一致，下一步不是扩大灰度比例，而是先补齐路径清单和环境对照，再决定是否发布。

这样做的意义在于：灰度不是用来证明“没问题”的，而是用来把例外提前暴露在可控范围内；一旦例外出现，处理动作和判断依据都能被复查。