缓存是站点性能的常規手段，但也會带来一類很难排查的問题：後台已经改好了，訪客和蜘蛛看到的還是舊版本。做站点运营时，把缓存当成一項需要定期自查的配置来對待，能省下很多“明明改了却没生效”的来回沟通。

缓存為什么會挡住更新的内容

站点通常有多层缓存同时在起作用：浏览器本地缓存、CDN 邊缘节点缓存、服務器端頁面缓存或對象缓存。一次請求可能被其中任意一层拦住，直接返回之前存下的副本，請求根本没走到源站。

對运营来说，這意味着两件事。第一，更新之後自己刷新能看到新内容，不代表別人也能看到，因為你這次訪問可能刚好绕過了某一层。第二，蜘蛛抓到的 HTML 如果来自邊缘节点的舊副本，那么新加的連結、調整過的标题、替換掉的正文，都不會立刻出現在它的抓取结果里。

分层自查：從浏览器到源站

1. HTML 和静態资源分開對待

静態资源（图片、样式、脚本）通常带指纹或版本号，可以设較長的缓存時間；而 HTML 是内容變更的主要载体，缓存時間往往需要短很多，或者使用协商缓存，让浏览器每次回源確認一下。

• 检查 HTML 响應头里的缓存指令，確認它的有效期是否合理，是否誤用了“一年不變”這類只适合带指纹资源的設定。
• 检查静態资源的文件名是否带版本或哈希。没有指纹又设了長缓存，改動後用戶會長期拿到舊文件。
• 確認頁面上的關键资源引用路径會随版本更新，而不是固定不變的地址。

2. CDN 的缓存键與查询參數

CDN 判断“這是不是同一個资源”，靠的是缓存键。如果缓存键忽略了查询參數，那么带不同參數的地址可能被当成同一個頁面，返回彼此的内容。

• 確認带參數的頁面（篩選、排序、分頁）是否被配置成忽略參數，導致不同结果互相覆盖。
• 確認是否對不存在的參數组合也做了缓存，避免把错誤頁面長期留在邊缘节点。
• 核對回源协议與回源地址，避免 CDN 走的是測試环境或舊机房。

3. 私有内容與登入態不要被公共缓存

後台頁面、用戶中心、带登入信息的頁面，如果被当成公共内容缓存，風險不只是内容不新，而是可能把一個人的頁面發给另一個人。這類地址應当明确排除在公共缓存之外，或按用戶区分缓存键。

4. 回源失敗时的兜底行為

有些配置在源站超时或报错时會返回之前缓存的舊副本。這在稳定性上有好處，但也會掩盖問题：源站其實已经挂了，外部看着却“一切正常”。自查时要確認這類兜底策略是否開啟、開啟後是否有告警。

發布完之後怎么驗證

更新上线後，建议固定走一遍检查流程，而不是只刷新一次頁面就結束。

1. 用無痕窗口打開目标地址，排除浏览器本地缓存的影响。
2. 查看响應头，確認返回的是新版本标记，而不是舊的缓存命中。
3. 如果站点有 CDN，主動提交需要刷新的地址，等待生效後再复查一次。
4. 用抓取工具或直接請求的方式，模拟蜘蛛拿到的 HTML，確認里面已经包含新内容。
5. 隔一段時間再复查一次，確認没有被邊缘节点用舊副本重新填充。

把缓存策略寫進运维记錄

缓存問题最容易在交接时出岔子：谁改過規則、什么时候清過缓存、哪些路径需要手動刷新，如果没有记錄，下一個人只能靠猜。可以在运维文档里固定记下几件事：各层缓存的有效期、缓存键的组成方式、需要手動刷新的路径清單、以及每次改版後执行刷新的時間点。

另外，站点结构或栏目調整时，记得同步检查舊的缓存規則。已经下线的目錄如果還留着長缓存配置，可能出現舊地址仍然返回内容的情况，给後續的規范化處理添麻烦。

缓存不是一次配置就一劳永逸的事。把它和内容更新节奏绑在一起，每次發布顺手確認一遍，比事後反复怀疑“是不是服務器有問题”要省事得多。