蜘蛛的請求很少直接落在你的源站上。多數站点前面有 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，對比返回头和正文，检查缓存里的版本是否已经過期。
缓存本身不是抓取的障碍，配置不当的缓存才是。让蜘蛛稳定地拿到正确版本的頁面，比让它每次都回源要划算得多。