做站点运营时，最容易忽略的一類問题不是頁面寫错了，而是頁面改了却没人看到。你把标题、正文、價格都更新了，訪客看到的還是舊版本，抓取工具拿到的也是舊版本。這往往不是發布失敗，而是缓存没有處理好。缓存本身是好東西，它能降低服務器压力、加快首屏速度，問题在于缺少規則和驗證。
先搞清楚改的是哪一层缓存
一次請求從浏览器到源站，可能经過好几层缓存。定位問题时，先把层次分清楚，比盲目刷新有效得多。
- 浏览器缓存：由 Cache-Control、Expires 等响應头控制，缓存在訪客本地，你無法遠程清理。
- CDN 或反向代理缓存：缓存在邊缘节点上，同一地区用戶可能共享同一份内容。
- 應用层缓存：頁面缓存、對象缓存、資料库查询缓存，常见于動態站点和框架层。
- 服務端脚本缓存：如 PHP 的 OPcache、模板编译缓存，改動後需要確認是否自動失效。
自查清單：更新之後要確認的几件事
1. HTML 文档不要設定長缓存
HTML 是内容的入口，建议使用較短的 max-age，或者 no-cache 配合 ETag、Last-Modified，让浏览器每次回源做一次校驗。真正适合長缓存的，是带版本指纹的 CSS、JS 和图片。
2. 静態资源用文件名指纹
修改样式或脚本时，同时更改文件名或加 hash 後缀，例如 style.3f9a2.css。這样舊文件可以繼續被缓存，新文件自然走新地址，不必依赖人工刷新节点。
3. CDN 缓存規則按目錄和類型区分
- 文章詳情頁：可以缓存几分钟到几十分钟，並允许回源校驗。
- 首頁和频道頁：按更新频率設定較短缓存，避免長期停在舊版本。
- 登入態、购物车、後台入口：不缓存，或按 Cookie 绕過缓存。
- 带參數的地址：確認規則是否忽略無關參數，別让每個跟踪參數都生成一份獨立缓存。
4. 主動刷新要有记錄
發布之後，明确知道需要刷新哪些 URL，並尽量通過接口批量提交，把刷新動作寫進發布流程。靠“等一會儿再看看”容易漏掉關键頁面。
一個可执行的驗證流程
- 用無痕窗口打開頁面，排除本地缓存干扰，確認内容是否為最新。
- 在開發者工具的 Network 面板查看 HTML 响應头，關注 Cache-Control、Age、ETag 以及 CDN 返回的命中标识。
- 換一個網絡环境或不同地区节点再請求一次，確認邊缘节点也已更新。
- 检查带參數的地址是否返回同样的内容，避免參數版本停留在舊頁。
- 查看最近的抓取记錄，確認抓取工具拿到的版本與後台一致。
缓存和内容更新之間的關系
抓取工具看到的是它抓取那一刻的版本。如果邊缘节点長期返回舊頁面，抓取结果就和後台内容不一致，更新可能很久都不被反映。所以缓存策略不只是性能問题，也關系到内容更新能否被及时發現。
常见誤区
- 把“清缓存”当成萬能药，每次改動都全站刷新，反而让缓存失去意义。
- HTML 和静態资源套用同一套長缓存規則。
- 只在本地測試，忽略了 CDN 邊缘节点的狀態。
- 移動端和桌面端共用缓存键，導致一端看到另一端的頁面。
- 忘记给 404、301 這類响應設定合适的缓存，让错誤结果被長期记住。
把缓存寫進發布清單
建议在每次内容發布或改版前，固定回答几個問题：本次改動了哪些 URL；這些 URL 经過哪几层缓存；是否需要主動刷新；刷新之後用什么方式驗證。把答案记錄下来，缓存就從一件凭感觉的事，變成流程里可以检查的一环。缓存的目标從来不是让内容永不更新，而是在响應速度和内容新鲜度之間找到合适的平衡点。