蜘蛛的请求很少直接落在你的源站上。多数站点前面有 CDN 或反向代理，请求先到边缘节点。如果这个 URL 在节点上已有缓存副本，蜘蛛拿到的就是缓存，而不是你服务器刚刚生成的那一份。理解这条链路，才能解释一些看起来"莫名其妙"的抓取现象：标题改了蜘蛛没更新、页面偶尔 5xx、同一地址前后抓到不同内容。
缓存键决定了蜘蛛能不能命中
边缘节点判断"这是不是同一个资源"，靠的是缓存键。常见缓存键包括域名、路径和查询串，有些配置还会把 User-Agent、Cookie、Accept-Encoding 算进去。缓存键拆得越细，同一份内容被拆成的副本越多，命中率越低，蜘蛛和真实用户都更容易打到回源。
如果站点做了移动端适配，用 Vary: User-Agent 让桌面版和移动版分开缓存，这是合理的。但要避免再把一堆无关的头信息塞进缓存键，否则蜘蛛的每个请求都像"新访客"，节点上永远缓存不住，回源压力会成倍放大。
命中与回源，对抓取节奏的影响
命中缓存时，响应往往在几十毫秒内返回，蜘蛛队列走得快，单次会话能多抓几个 URL。一旦大量请求需要回源，源站响应时间上升，超时和 5xx 出现的概率增加，蜘蛛会收缩抓取量，这段时间里新 URL 的发现也会被顺延。
另一个容易被忽略的问题是版本一致性。如果缓存 TTL 很长，蜘蛛可能长时间只见到旧版本页面；内容更新后只改了源站、没刷新缓存，回爬就基本白跑一趟。
几个常见的配置坑
- 给搜索引擎的 UA 单独设置"绕过缓存"。出发点是让蜘蛛看到最新内容，结果是每次抓取都回源，抓取量一大就把源站压慢。
- 把 404、410 或者空结果页也缓存下来。页面内容补齐之后缓存副本还在，蜘蛛继续拿到旧状态。
- TTL 设置过短，比如几十秒，缓存几乎不起作用，等于没有缓存。
- 发布内容后整站批量刷新缓存，瞬时回源请求集中打向源站，容易触发限流或 5xx。
- 缓存键里包含了每次都会变化的 Cookie，导致几乎人人不命中。
多站点共用一套源站时要注意什么
如果同一套源站挂着多个域名，先确认缓存键包含 Host，否则不同域名可能共用同一份缓存副本，蜘蛛抓到的内容与域名预期不符。反过来，每个域名都单独写一套缓存策略，规则会变得难以维护，建议先在测试域名上验证一套通用规则，再逐步放开。
可落地的做法
- 先确认缓存键里到底有哪些维度，把不必要的头信息去掉。
- 为页面类 URL 设置合理的 TTL，既不要几分钟就过期，也不要几个月不更新。
- 内容变更时按 URL 精准刷新，而不是整站刷新。
- 尽量不要让搜索引擎 UA 走"永久绕过缓存"的策略。
- 把回源率和源站响应时间当作抓取是否顺畅的前置指标来盯。
怎么确认蜘蛛拿到的是哪一份
把蜘蛛的抓取日志和 CDN 访问日志对齐，看缓存命中状态字段和 Age 值，能直接判断某次抓取是命中还是回源。也可以用带缓存标识的请求自己访问同一 URL，对比返回头和正文，检查缓存里的版本是否已经过期。
缓存本身不是抓取的障碍，配置不当的缓存才是。让蜘蛛稳定地拿到正确版本的页面，比让它每次都回源要划算得多。