缓存的初衷是让重复訪問更快，但配置不当的时候，它會變成另一種麻烦：訪客看到的是上一次改版前的頁面，抓取到的也是舊内容，而你在後台明明已经儲存並發布了。缓存本身没有错，問题通常出在没人说清楚“哪一层缓存、缓存多久、谁来清”。
先分清站点上的几层缓存
排查之前，先把鏈路上的缓存层數清楚，否則很容易改了一层、漏了另一层。
- 浏览器缓存：由响應头控制，缓存在訪客本地，服務端無法主動清除，只能等它過期或靠用戶手動刷新。
- CDN 或反向代理缓存：位于机房邊缘，一般可以主動刷新，但需要知道具体节点和匹配規則。
- 應用层缓存：頁面片段、資料库查询结果、對象缓存等，常和發布流程绑定，容易被忽略。
- 模板或静態化缓存：生成 HTML 文件後没有随内容更新而重新生成，頁面看上去一直停在舊版本。
看响應头，比翻文档更快
用浏览器開發者工具的 Network 面板或命令行查看响應头，重点看几個字段：Cache-Control 里的 max-age 與 s-maxage，是否带着 no-store、no-cache、private；Expires 與 max-age 是否互相冲突；ETag 和 Last-Modified 是否稳定。如果 HTML 文档被设成很長的 max-age，又没有版本化的文件名兜底，更新就會變得很別扭。
一個常见的经驗分界：HTML 文档适合較短的缓存時間或协商缓存，带内容指纹的静態资源才适合長缓存。
静態资源和 HTML 要区別對待
把两者混在一起配置是常见的坑。静態资源文件名里带上内容哈希，就可以放心設定一年期的强缓存；而 HTML、接口响應這類随时可能變化的内容，要么短缓存，要么走协商缓存。否則每次更新都得靠手動刷新 CDN，時間一長就没人记得做了。
缓存與内容更新的矛盾怎么處理
- 發布後主動刷新相關 URL 的 CDN 缓存，並把這一步寫進發布流程。
- 首頁、列表頁這類被频繁缓存的頁面，缩短缓存時間或加上短时校驗。
- 改版期間给關键頁面加版本标记，避免新舊模板混着輸出。
- 驗證时用無痕窗口或带禁用缓存選項，排除本地缓存带来的错觉。
關于抓取侧的观察
蜘蛛拿到的頁面同样受缓存层影响。如果 CDN 長期返回舊版本，抓取结果就與目前内容不一致。可以在發布後观察一段時間服務器日誌里對目标 URL 的抓取记錄，確認返回内容與预期一致。這件事没有捷径，只能靠發布後回看，而不是發完就当結束。
一份可执行的自查清單
- 列出站点用到的所有缓存层，寫清各自的開關位置和生效范围。
- 抽查首頁、栏目頁、詳情頁、静態资源的响應头，判断缓存策略是否合理。
- 確認 HTML 與带指纹的静態资源没有共用同一套缓存規則。
- 確認發布流程中包含刷新缓存的步骤，並明确由谁负责。
- 改版或紧急修正後，用無痕模式確認訪客實际看到的内容。
- 留一份“缓存異常时的處理顺序”，避免临时手忙脚乱。
缓存策略不需要多复杂，關键是有人知道它存在、知道怎么改、知道什么时候该清。把這几件事固定進日常运维清單，比事後一遍遍猜“為什么頁面没更新”要省事得多。