蜘蛛抓取一個 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 發現和内鏈判断都會跟着偏。
把缓存刷新寫進發布流程，比事後反复提交地址更省事。日常巡检时，顺手看一眼邊缘节点返回的版本和源站是否一致，就能提前發現大部分由缓存引起的新舊内容错位。