CDN 帮站点分担流量，也带来一個副作用：内容更新之後，邊缘节点上還留着舊版本。用戶看到的是舊頁面，蜘蛛抓到的也可能是舊頁面。反過来说，如果缓存配置得太松，回源压力又會明顯上升。缓存這件事，值得按固定节奏自查一遍。
先確認問题是否真的存在
判断缓存有没有捣乱，最直接的办法是對比。用 curl -I 請求同一個地址，分別带随机參數與不带參數，查看响應头里的 Age、X-Cache、Cache-Control、ETag、Last-Modified。如果某個节点返回的 Age 很大，而頁面内容早已更新，說明之前的刷新並没有覆盖到全部节点。有條件的话，再從不同地区或不同运营商訪問一次，對照頁面正文是否一致。
一份務實的自查清單
- 静態资源（图片、CSS、JS）是否带内容指纹，例如文件名里包含 hash 或版本号，並配置了較長的缓存時間。
- HTML 頁面是否被设成了長期强缓存。列表頁、资讯頁通常更适合較短的缓存時間，甚至不缓存 HTML，让内容由回源决定。
- 缓存键都包含哪些维度：Host、路径、查询參數、語言或地区信息。少算一個维度，就可能把两種内容混成一份缓存。
- 带 Cookie 的請求和匿名請求是否被同等對待，避免登入用戶看到游客頁面，或者反過来把私人内容缓存出去。
- 後台、预览、接口、购物车這類路径，是否在規則里被明确排除在缓存之外。
- 404、301、302 這些响應有没有被缓存住。一個错誤狀態被邊缘节点记住，可能持續给用戶和蜘蛛错誤信号。
- 是否配置了回源超时和失敗兜底，避免回源異常时直接返回空白頁。
刷新與预热要分层
内容更新後，刷新方式需要分清影响面：單條 URL 刷新最精准，但配額有限；目錄刷新影响較大，容易把正常缓存一並清掉；全站刷新只在萬不得已时使用。刷新完成之後，可以主動請求一次目标地址做预热，让第一個訪問者不必承担回源等待。
缓存與抓取之間的關系
蜘蛛来訪时不會等你走完刷新流程。刷新没做完，它抓到的可能就是舊版本；如果地址没變、内容却大幅調整，舊缓存與新頁面之間還可能出現信号不一致。比較稳妥的做法是：正文更新尽量沿用原地址，把缓存刷新與内容發布放在同一個流程里；重要改動前後，用訪問日誌確認蜘蛛實际拿到的响應與线上一致。缓存只决定“看到什么”，並不决定是否被收錄，不必把刷新当成收錄手段。
把“刷新缓存”寫進發布流程的固定步骤，顺序可以是：先發布到源站，再刷新，最後抽检几個 URL。
可以落地的几條习惯
- 维護一份缓存規則清單：哪些路径强缓存、哪些不缓存、各自缓存多久、最近一次改動是谁做的。
- 發布後抽检三到五個有代表性的 URL，在無痕窗口和带參數的情况下各訪問一次，確認内容一致。
- 關注回源比例與命中率，如果某天突然下降，往往說明缓存键或規則被改動過。
- 把缓存配置纳入改版、換 CDN、調整域名的上线检查項，不要等用戶反馈才發現問题。
缓存不是設定一次就能長期不管的事。規則、刷新方式、發布流程三者對齐之後，站点才能既保持速度，又不至于给出前後矛盾的内容。