搜索引擎爬虫：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a38c6c5f2f8d.html
📄
搜索引擎爬虫：异常恢复后怎样区分缓存过期与真正修复
先给判断标准：如果异常恢复后，同一 URL 的响应头、正文和抓取频率在多个独立请求中同步改善，并且改善发生在服务端变更之后，才更接近真正修复；如果只有展示层结果变好，而服务端响应仍与变更前一致，则更可能是缓存过期或中间层刷新。最容易被误判的情况是：你修复了源站，但爬虫仍拿到旧缓存，于是看起来“没修好”；反过来，缓存恰好过期，也会让你误以为修复生效。
矛盾现象：源站已改，抓取结果却先坏后好
假设一个页面因错误的状态码被大量抓取失败。你修正了服务端逻辑，但接下来几天抓取失败数先上升再下降。此时至少有两个解释：一是缓存层仍保存旧响应，爬虫继续命中旧版本，等缓存过期后才拿到新版本；二是修复本身不完整，部分节点或部分参数路径仍返回旧行为，失败数下降只是抽样波动。两者都会表现为“先坏后好”，不能只看一个总量曲线就下结论。
解释一：缓存过期造成的假恢复
缓存过期的典型证据是时间边界清晰。你可以记录变更部署的准确时间，然后对比同一 URL 在不同时间点的响应头。如果 Age 从较大值突然归零，或 Cache-Control 的 max-age 到期后响应正文才变化，说明变化点更接近缓存生命周期，而不是你的代码逻辑。另一个信号是不同网络位置结果不一致：同一 URL 从两个出口请求，一个拿到新正文，一个仍拿到旧正文，且旧正文对应的缓存键包含你未清理的维度，例如查询参数、Cookie 或协议差异。
解释二：真正修复造成的稳定变化
真正修复的证据是变化与缓存周期脱钩。部署后第一次请求就返回新状态码和新正文，并且在缓存未过期的窗口内重复请求仍保持新结果；清理缓存后结果不变；更换请求出口后结果不变。此时抓取失败数下降只是结果之一，不是证据本身。更可靠的证据是服务端日志中同一路径的响应码分布发生位移，并且位移出现在部署之后、缓存过期之前。
能区分两者的证据：一次可执行的回滚对照
一个实际动作是：在低流量时段，对同一组 URL 做两次请求，中间不改变任何服务端配置，只改变请求出口或清除你控制的缓存。记录每次的响应码、正文摘要和响应头。如果清除缓存后结果立刻变好，且再次命中缓存后又回到旧结果，说明缓存仍是主导因素；如果清除缓存前后结果一致，且回滚部署后结果重新变坏，说明修复本身在起作用。这个对照的关键是“只改一个变量”，否则无法归因。
抓取频率与索引结果不能单独证明修复
抓取量回升、索引量增加或某个查询下展示恢复，都不能单独证明源站已修复。抓取量可能因重试、站点地图更新或爬虫调度变化而上升；索引结果可能来自旧缓存副本；展示恢复也可能只是查询意图变化。要确认修复，至少要把服务端响应、缓存状态和抓取日志放在同一时间轴上核对。若只有展示层改善，而服务端响应码和正文未变，优先怀疑缓存或中间层，而不是认定修复完成。
因此，判断顺序应是：先确认服务端变更时间和缓存策略，再用清除缓存与回滚部署做对照，最后才看抓取和索引层面的变化。只有当你控制的缓存被清除后结果不变、回滚后结果重新变坏，才可以把改善归因于真正修复。
