很多站点都遇到過這種情况：編輯在後台發布了新版本，自己刷新能看到，但訪客、同事甚至搜尋引擎抓到的仍然是舊頁面。排查半天發現代碼没問题，問题出在缓存——更新确實寫進了源站，但某一层缓存還捧着舊副本。
先數清楚鏈路上有几层缓存
缓存不止一层，出問题时容易只盯着其中一层。一條典型的訪問鏈路里，可能同时存在下面這些缓存：
- 浏览器本地缓存，受 Cache-Control、Expires 等响應头控制；
- CDN 邊缘节点缓存，按 URL、目錄或文件後缀命中規則；
- 源站前面的反向代理缓存，如 Nginx proxy_cache、Varnish；
- 應用层的頁面缓存或整頁静態化；
- 對象存储、图床自带的缓存與版本控制。
建议把這條鏈路画在一張纸上，标注每层的過期時間、清除方式和负责人。很多时候“刷新了没生效”，只是因為刷新的不是真正命中的那一层。
HTML 和静態资源要分開對待
把 HTML 和 JS、CSS、图片用同一套缓存策略，是最常见的失誤。两者的更新频率完全不同：
- 带哈希或版本号的静態资源：内容變了文件名就變，可以放心設定較長的缓存時間，减少重复請求；
- HTML 文档：更新频繁，缓存時間要短，或者干脆不缓存，也可以考虑 stale-while-revalidate 這類先返回舊版、後台再更新的策略；
- 接口與動態資料：按业務容忍度單獨设定，不要跟着静態资源一起走長缓存。
如果 HTML 被设成了几天甚至更長的强缓存，那么無论後台怎么更新，訪客和爬虫看到的都會是上一版内容。
發布之後要做的几步
把下面這些動作寫進發布流程，比事後排查省事得多：
- 發布完成後，主動刷新對應的 CDN 缓存，按 URL 刷新還是按目錄刷新，取决于改動范围；
- 確認刷新請求調用成功，而不是只点了一下按钮；
- 用命令行工具查看响應头，關注缓存命中标识、Age、Cache-Control 等字段；
- 換個網絡或地区再訪問一次，確認不是只有本地节点更新了；
- 把刷新時間、刷新范围记在更新日誌里，方便和抓取记錄對照。
別让缓存掩盖真實的故障
缓存能扛住流量，也能藏住問题。源站返回的错誤頁如果被缓存下来，影响會一直持續到過期為止。
几類需要特別留意的场景：源站短暂返回 5xx 被邊缘节点缓存，用戶長時間看到报错；回源失敗後的預設頁被当成正常内容；缓存键設定過粗，把不同參數、不同登入狀態的頁面混成同一份。可以给错誤狀態碼設定很短的缓存時間，或者明确不缓存非 200 响應。
缓存對抓取的影响
搜尋引擎抓取时同样會经過缓存层。返回舊内容一般不會直接引發嚴重後果，但可能让内容更新被感知得更晚，尤其在更新频率較高的栏目里。另外要注意响應头中的 Vary 設定，如果按 User-Agent 或编碼区分缓存，配置不当會让同一地址出現多種返回结果，增加判断成本。
一個简單的自查节奏
- 内容更新当天：刷新缓存並抽查頁面；
- 每周：看一次缓存命中率與回源量，異常波動往往對應配置問题；
- 每次調整缓存規則：先在測試域名驗證，再全量生效；
- 每季度：复核一遍缓存时長，把已经不需要的規則清理掉。
缓存策略没有一劳永逸的答案，站点規模、更新频率和服務器配置都會影响選擇。關键是把每一层寫在文档里、把刷新動作放進流程里，让“更新完成”這件事在用戶和爬虫那一侧也真正成立。