死链接：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c5aa8667bd7b.html
📄
死链接：异常恢复后怎样区分缓存过期与真正修复
先给有条件的结论：如果修复后同一 URL 在多次独立请求中稳定返回目标状态，且响应头与内容都指向新版本，才能初步判定为真正修复；若只是某一次请求变正常、换个网络或换台机器又回到旧状态，优先怀疑缓存过期而非源站已改。这个判断成立的前提是你能控制请求路径并拿到可比较的响应证据，一旦样本扩大到不同 CDN 节点、不同爬虫 UA 或不同地区出口，结论就可能失效。
缓存过期与真正修复在证据上的分岔点
两者的核心差别在于“状态是否依赖请求路径”。缓存过期通常表现为：同一时刻不同节点结果不一致，或者短时间内先坏后好再坏；真正修复则表现为源站返回稳定，缓存层只是逐步跟进。判断动作是固定一个 URL，分别从本机、服务器直连和至少一个第三方节点发起请求，记录状态码、响应头中的缓存相关字段和页面正文片段。如果直连源站已经稳定正常，而外部节点仍返回旧结果，说明修复已落到源站，剩下的是缓存同步问题；如果直连源站仍异常，则缓存过期只是表象，问题还在源站或应用层。
这一步的结果直接决定下一步：源站正常就继续观察缓存收敛，源站异常就回到修复流程，而不是反复刷新外部请求。
一个会让结论失效的反例：软 404 与错误页
假设某批死链接在修复后，外部请求返回 200，但正文是站点通用错误页或空白模板。此时“200 即修复”不成立。可区分原因的证据是比对正文特征：真正修复的页面应包含目标内容的关键片段、正确的标题和站内链接；软 404 或错误页往往只有导航和页脚，正文长度明显偏短。另一个反例是重定向链：修复后返回 301 到新地址，但新地址本身又是死链接，表面状态码正常，实际用户仍走不到内容。
这类情况下，缓存过期与真正修复的判断必须让位于内容核验。动作是先确认最终落地页可访问且内容匹配，再回头判断缓存层是否已同步。
规模化后为什么个别样本的结论不能照搬
单条 URL 修好，不代表同类死链接都已修复。常见例外包括：同一模板生成的页面只有部分重新发布；旧链接被多个入口引用，只改了其中一个；缓存键包含查询参数或 UA，导致部分请求仍命中旧缓存。边界条件是：只有当同类 URL 共享同一发布路径、同一缓存策略时，单样本结论才可外推。否则应抽样覆盖不同目录、不同模板和不同入口来源。
动作上，先按目录或模板分组，每组抽若干条做同样的直连与外部对比。如果某组直连正常、外部异常的比例高，优先处理缓存刷新；如果某组直连也异常，说明发布未覆盖该组。
把判断落成可执行的下一步
- 固定一组待验证 URL，记录直连源站与外部节点的状态码、响应头和正文关键片段。
- 直连正常而外部异常：提交缓存刷新或等待过期，并记录刷新前后的对比结果。
- 直连仍异常：回到发布或应用层排查，不要用缓存解释掩盖源站问题。
- 抽样扩大到不同目录和模板，确认结论是否只对个别样本成立。
每一步的结果都会改变下一步方向：直连与外部一致且内容正确，才可以把该组标记为已修复；只要有一项不一致，就应保留为待观察，而不是直接宣布恢复完成。这样做的目的是避免把一次缓存过期误判为修复成果，也避免把源站未修的问题归因于缓存。
