缓存是站点运营里最容易被忽略、又最容易出事故的一环。它平时不声不响，一旦配置不当，訪客看到的是几天前的首頁，蜘蛛抓到的是一份已经改過的舊内容，客服和运维就會被同一批問题反复轰炸。缓存本身没有错，错的是没人定期看它。
缓存到底缓存了什么
從訪客按下回车到頁面出現，中間可能经過好几层缓存：浏览器本地缓存、中間的 CDN 或反向代理、應用层的頁面缓存與對象缓存、資料库查询缓存。每一层都有自己的過期時間和判断依據，任何一层没對上，结果就會不一致。
自查的目的不是把所有缓存關掉，而是让每层缓存知道自己该存多久、什么时候该失效。對静態资源可以放長一点，對會變動的頁面就要短一些，對带用戶身份的响應則不该被公共缓存儲存。
先看响應头
Cache-Control 是主開關
- max-age：浏览器可以复用的秒數。
- s-maxage：只對 CDN、代理這類共享缓存生效，優先級高于 max-age。
- no-cache：不是不缓存，而是每次使用前必须回源校驗。
- no-store：完全不落盘，适合登入態、訂單等敏感頁面。
- must-revalidate：過期後必须回源，不能拿舊的凑合。
校驗头决定回源成本
ETag 和 Last-Modified 让服務器可以用 304 告诉訪客“内容没變”，省下重复传輸。如果這两個值每次請求都在變，比如時間戳參與了生成，浏览器就永遠走全量下载，缓存等于白设。
Vary 別漏
如果站点會根據设备、語言或压缩方式返回不同内容，Vary 头要如實声明。否則共享缓存可能把移動端頁面發给桌面訪客，或者反過来。
逐层自查怎么做
- 用浏览器開發者工具的 Network 面板查看關键頁面的响應头和實际耗时，確認命中的是缓存還是回源。
- 用命令行工具分別請求带與不带缓存头的地址，對比返回体和响應碼。
- 在 CDN 後台查看缓存命中率與回源量，命中率過低先查缓存規則是否被某些參數绕過。
- 检查是否存在把带查询參數的地址当成不同资源缓存，導致同一頁面被存了很多份。
- 對後台、登入頁、支付回調這類地址確認没有被公共缓存儲存。
容易被忽视的几個坑
- 發布新版本後只刷新了首頁，内頁和静態资源仍指向舊文件。
- 给静態资源加了長缓存，文件名却没有指纹或版本号，更新後訪客一直拿舊文件。
- 缓存規則寫得太宽，把接口返回也缓存了，導致資料滞後。
- 換服務器或換 CDN 後忘记同步舊規則，出現两套策略打架。
- 頁面缓存和應用缓存各自為政，清了一處另一處還在生效。
日常维護建议
把缓存策略寫進上线流程：改版前先確認影响范围，改版後按资源類型分別處理。可以给静態资源配置带指纹的文件名加長缓存，给 HTML 設定較短的缓存或协商缓存。建立一份缓存規則记錄，注明每條規則的路径范围、生效時間和负责人，避免時間久了没人记得為什么這么配。
缓存不是设好就不用管的一次性工作。它和内容更新、服務器變更、CDN 調整绑在一起，任何一處動了，都值得回来看一眼。