CDN 的作用是把内容放到离用戶更近的节点上，减少回源压力。但缓存一旦配置不当，蜘蛛和用戶拿到的可能是几個小时甚至几天前的舊頁面。新内容已经發布，抓取结果里却還是舊标题、舊價格、舊库存，這類問题在运营中並不少见。
先確認蜘蛛看到的是不是缓存版本
最直接的办法是用不同的 User-Agent 請求同一個 URL，比較响應头和正文。如果返回头里带有 Age、X-Cache: HIT 之類的字段，說明命中了缓存。再對比源站直接訪問的结果，就能判断缓存是否把舊内容暴露出去。
也可以借助日誌：如果某個 URL 在源站日誌里長時間没有记錄，但頁面明明有更新，可能是 CDN 一直在用缓存响應蜘蛛，源站根本没收到請求。
缓存键和缓存时長要分清
- 缓存键：有些 CDN 預設把查询參數、Cookie、User-Agent 都算進缓存键，導致同一篇内容被缓存很多份；也有些配置忽略查询參數，把不同參數頁面混成同一個缓存。需要结合站点實际情况確認。
- TTL：静態资源可以设長一些，HTML 頁面通常不宜太長。新闻、商品、活動頁這類更新频繁的内容，TTL 需要更短。
- 回源規則：哪些請求必须回源、哪些可以命中缓存，最好按目錄或内容類型区分，而不是全站一個策略。
更新之後要主動刷新
發布新内容、修改标题或價格後，如果只等 TTL 自然過期，蜘蛛可能在缓存過期前反复抓到舊版本。常见的做法是通過 CDN 提供的刷新接口提交 URL，或者把内容管理系統和刷新動作绑定在一起。
刷新时注意范围
刷新單個 URL 比整站刷新更可控，整站刷新容易在短時間内造成回源压力。列表頁、首頁、栏目頁和詳情頁的刷新優先級也不一样，詳情頁通常最需要及时更新。
別忽略缓存分层
有些 CDN 有多层缓存，邊缘节点刷新了，中間层可能還有舊副本。刷新後最好再驗證一次實际响應，而不是提交完就認為已经生效。
几個容易踩的坑
- 把带 Set-Cookie 的响應缓存下来，導致不同用戶看到同一份登入態頁面。
- 忽略 Vary 头，把移動端和桌面端頁面混用同一份缓存。
- 源站更新後没有通知 CDN，缓存一直保留舊版本。
- 把 404 或 500 错誤頁也缓存住，错誤狀態被持續返回。
缓存的目标是让重复請求更快，不是让所有請求都變成缓存。该回源的时候要回源，该刷新的时候要刷新。
自查之後做什么
建议定期抽查重点頁面的响應头，记錄缓存命中情况和 TTL 設定。把更新频繁的栏目單獨列出来，配置更短的缓存時間或自動刷新。對蜘蛛和用戶都重要的頁面，尽量保證源站内容、CDN 缓存和頁面展示三者一致。
如果站点同时使用蜘蛛池或主動推送来辅助 URL 發現，也要注意推送的 URL 是否會被 CDN 缓存返回舊内容。發現和抓取只是第一步，抓到的内容是否新鲜，同样影响後續判断。