内容已经發布，訪客却说“還是老样子”；後台資料改了，前台價格没變；运营同学反复刷新，只有自己电脑上是新的。遇到這類反馈，先別怀疑發布流程，多半是缓存没刷新。缓存本身不是問题，問题在于我們不知道内容卡在哪一层、该在哪里清。
先把缓存的层數分清楚
一個頁面從服務器到訪客屏幕，中間可能经過好几层缓存。排查之前，先列清楚自己的站点有哪些：
- 浏览器缓存：訪客本地儲存的副本，由响應头里的 Cache-Control、Expires 决定。
- CDN 邊缘缓存：离訪客最近的节点，命中後不再回源，是“只有我這里變了”的常见原因。
- 反向代理或服務端缓存：Nginx、Varnish 之類，按 URL 或規則缓存整頁。
- 應用层缓存：對象缓存、片段缓存、模板编译缓存。
- 静態化文件：部分站点會生成 HTML 文件直接對外，更新後需要重新生成。
层級越多，命中越快，但排查鏈路也越長。建议给自己画一張简單的图，标出每层缓存的存放位置和清理入口，出問题时不至于到處乱找。
確認内容卡在哪一层
- 用浏览器無痕窗口打開，或換一台设备、換一個網絡，例如從 Wi-Fi 切到手机流量。如果換網絡後内容變新，多半是 CDN 邊缘节点的問题。
- 用 curl -I 或開發者工具的 Network 面板看响應头，重点關注 Age、X-Cache 之類的字段。Age 數值很大，說明命中的是較舊的副本。
- 在 URL 後加一個随机參數再訪問。若带參數是新内容、不带參數是舊内容，基本可以确定是缓存，而不是發布失敗。
- 看 CDN 後台的命中率與刷新记錄，確認上一次刷新有没有真正下發到所有节点。
- 如果只有登入用戶看到舊内容，检查是不是把带 Cookie 的响應也缓存了。
缓存策略怎么设更省心
原則很简單：變化越频繁的東西，缓存時間越短；文件名带版本号的静態资源，可以放心缓存久一点。
- HTML 頁面建议設定較短的 max-age，配合 ETag 或 Last-Modified 做协商缓存，让浏览器每次都能確認一下。
- CSS、JS、图片等静態资源用内容哈希命名，設定長期缓存。更新时改文件名即可，不必反复刷 CDN。
- 接口類請求按业務区分，涉及库存、價格、登入態的响應不要走公共缓存。
- 更新内容後主動調用 CDN 刷新接口，把首頁、栏目頁和该篇詳情頁一起刷掉，別只刷一個。
缓存排查有一個很實用的习惯：任何一次“改完没生效”的反馈，先問清楚對方用的什么網絡、什么浏览器、是否登入，再動手清缓存。信息越具体，定位越快。
几個容易忽略的坑
- 把 404 或错誤頁長時間缓存，導致頁面恢复後訪客仍然看到错誤内容。
- CDN 层面忽略查询參數，把不同篩選條件的列表頁当成同一個頁面返回。
- robots.txt、sitemap 被缓存過久，規則更新後仍需等待較長時間才生效。
- 刷新缓存时只刷了带 www 的域名，没刷裸域或 https 版本。
- 上线後忘了重新生成静態化文件，源站更新了、對外文件還是舊的。
更新内容时的一套固定動作
- 確認發布成功，先在源站直接訪問，看内容是否正确。
- 刷新该 URL 的 CDN 缓存，必要时按目錄前缀批量刷新。
- 用無痕窗口和手机流量各訪問一次，確認訪客侧看到的是新版本。
- 检查頁面的标题、描述、结构化資料是否同步更新，避免只改了正文。
- 记錄本次操作時間與涉及 URL，方便下次遇到類似問题时對照。
缓存做得對，站点會更快、更稳；做得糊涂，就會變成“我這邊好了，別人那邊没變”的反复拉扯。把每一层缓存的位置、策略和刷新入口寫進运维记錄，比临时找人清缓存要可靠得多。