死链修复工具，异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7175f264fe98.html
📄
死链修复工具，异常恢复后怎样区分缓存过期与真正修复
先给结论：异常恢复后看到的状态改善，多数只是缓存过期，不等于死链已被真正修复。判断依据不是“现在能不能打开”，而是源站响应、缓存层响应和抓取端响应三者是否一致，并且这种一致性能在缓存自然过期后继续维持。个别样本成立，不代表规模化后成立；样本越多，例外越容易暴露。
先分清两种“恢复”：缓存过期与源站修复
缓存过期是时间到了，缓存层把旧结果丢掉，重新回源取了一次；源站修复是源站本身不再返回错误状态，任何时间、任何节点回源都得到正常结果。前者会随缓存策略反复出现，后者不会。
可以这样区分：
- 缓存过期：第一次探测是错误状态，等待一段时间后变成正常，但换一个未命中缓存的节点或加随机查询参数再次请求，又回到错误状态。
- 真正修复：无论是否命中缓存、无论从哪个节点请求，源站都返回正常状态，且持续多个观察周期。
关键动作是绕过缓存直接看源站。如果源站仍然返回错误，而缓存层显示正常，那这次“恢复”只是缓存过期，后续还会复发。
条件一：有独立源站探测能力时，先验证源站再信任缓存
如果死链修复工具能分别报告缓存层状态和源站状态，处理顺序应是先确认源站。具体动作：对同一批 URL 分别请求缓存命中和强制回源两种路径，记录状态码与响应体是否一致。
结果如何影响下一步：
- 源站与缓存层都正常，且连续多个周期一致，可以进入规模化验证。
- 源站错误、缓存层正常，说明只是缓存过期，不能扩大修复范围，应回到源站修配置。
- 源站正常、缓存层错误，说明缓存需要主动清理或等待过期，修复本身可能已生效，但对外表现仍不稳定。
假设一个短例子：某批 URL 在修复后第一次检测全部返回正常，但强制回源请求仍返回错误状态。此时若直接判定修复成功，规模化后会再次出现大量异常。正确做法是先把这批样本标记为“待确认”，等源站响应稳定后再判定。
条件二：无法独立探测源站时，用时间与路径交叉验证
如果工具只能看到最终抓取结果，无法区分缓存层和源站，就要用时间和请求路径做交叉验证。动作是：在同一批 URL 上，间隔多个时间点重复检测，并在每次检测中混入带随机参数的请求。
判断依据：
- 只有固定时间点正常、随机参数请求异常，倾向缓存过期。
- 固定时间点和随机参数请求都正常，且跨多个时间点稳定，倾向真正修复。
- 结果在正常与异常之间反复跳动，说明缓存策略或源站配置仍不稳定，不能按已修复处理。
这里有一个边界：随机参数请求本身也可能被缓存策略区别对待，所以它只能作为辅助证据，不能单独作为结论。规模化后，样本量越大，缓存层差异越容易被放大，个别样本的结论越不能直接照搬。
规模化后为什么例外变多：缓存分层与抓取限制
小批量样本可能刚好命中同一缓存节点，结论看起来干净；规模化后请求分散到不同节点、不同缓存层级，就会出现部分正常、部分异常。这不是修复失效，而是缓存过期时间不一致导致的表象差异。
另一个常见干扰是抓取限制。robots.txt 的抓取限制不等于可靠的索引移除，它只约束抓取行为，不决定已有结果是否被替换。站点地图也不保证收录，提交后仍需观察实际抓取和索引结果。因此，抓取端显示正常，不能直接推断死链已被真正修复。
还要注意：不同搜索引擎对缓存、抓取和索引的处理方式不同，支持情况须分别核查。把某一个引擎的表现当作全部结论，规模化后必然出现例外。
可执行的最小判定流程
把判定拆成可重复的动作，而不是一次性看结果：
- 选取一批异常恢复的 URL，记录首次检测时间、状态和响应来源。
- 对同一批 URL 做强制回源请求，区分源站状态与缓存层状态。
- 间隔多个周期重复检测，混入随机参数请求，观察结果是否稳定。
- 只有源站正常、缓存层正常、跨周期稳定三项同时满足，才标记为真正修复。
- 任何一项不满足，保留在观察列表，不扩大到全量。
这个流程的价值在于：它把“看起来恢复了”拆成可验证的条件，避免把缓存过期误判为修复完成。规模化后，例外会告诉你边界在哪里，而不是推翻整个判断方法。
