蜘蛛抓取一个 URL 时，请求往往不会直接落到源站，而是先经过 CDN、反向代理或页面缓存层。如果缓存命中，蜘蛛拿到的就是一份已经存在的副本。这份副本是否等于最新内容，决定了它这一次抓取能发现什么。
缓存命中时，蜘蛛看到的是哪一份页面
缓存命中会明显降低响应时间，蜘蛛在同样的抓取窗口里更容易把请求完成。但缓存同时也隔开了一层：源站更新了 HTML，边缘节点如果还在 TTL 内，返回的仍是旧版本。旧版本里可能有已经删除的链接、指向旧地址的 canonical，以及上一版的标题和摘要。对以 URL 发现为目标的抓取来说，这等于让蜘蛛沿着一条已经不存在的路径继续往下走。
三类容易出问题的缓存场景
更新后没有主动刷新
内容发布、栏目调整、URL 改版之后，如果发布流程里没有清缓存这一步，蜘蛛很可能在几个小时甚至几天内持续读到旧页面。列表页尤其明显：新文章没有出现在缓存副本里，蜘蛛自然顺着旧链接走，新 URL 迟迟不被发现。
按 UA 或 Cookie 做了缓存分流
有些站点会对不同 UA 返回不同内容，比如给爬虫一个精简版、给用户完整版。缓存键一旦包含 UA 或 Cookie，蜘蛛拿到的版本就与用户不同，链接数量、正文完整性都可能缩水。Vary 头设置不当也会造成类似结果。
多节点之间副本不一致
蜘蛛的出口 IP 很多，同一时刻可能命中不同的边缘节点。如果节点之间缓存不同步，同一个 URL 在短时间内会返回多个版本，抓取结果不稳定，日志里也会出现同一页面响应体大小反复变化的情况。
实际可做的几件事
- 发布和改版后，主动刷新受影响 URL 的缓存，列表页和首页优先。
- HTML 文档设置较短的 TTL，图片、CSS、JS 等静态资源可以用长缓存。
- 不要按爬虫 UA 返回与用户不同的正文内容，链接也要保持一致。
- 检查 Vary 头，确认没有因为 Cookie 或语言头把缓存拆得过细。
- 保留一条能直连源站的测试通道，方便对比缓存版本。
缓存快，抓取就一定多吗
不必然。响应时间变短会减少超时和中断，蜘蛛完成一次请求的成本更低，但抓取总量仍受抓取预算、站点整体质量和内链结构影响。缓存层的作用是让源站压力更小、蜘蛛少遇到超时，而不是直接换来更多抓取次数。
出现异常时的排查顺序
- 从不同节点、不同 UA 请求同一个 URL，对比返回的 HTML 与 Age、X-Cache 等响应头。
- 直连源站请求同一 URL，确认源站输出是否已经是新版本。
- 翻抓取日志，看蜘蛛拿到的响应码与响应体大小是否与预期一致。
- 确认发布流程里是否有清缓存步骤，是否覆盖了列表页与详情页。
- 检查错误页是否被缓存：404、503 页面如果被缓存住，蜘蛛会在较长时间里持续读到错误状态。
缓存不决定内容好不好，它只决定蜘蛛这次打开的是哪一份副本。版本对不上，后面的 URL 发现和内链判断都会跟着偏。
把缓存刷新写进发布流程，比事后反复提交地址更省事。日常巡检时，顺手看一眼边缘节点返回的版本和源站是否一致，就能提前发现大部分由缓存引起的新旧内容错位。