内容更新發布後，後台顯示已儲存，前台訪問却還是舊版本。這種情况不一定發布失敗，很多时候是缓存没有刷新到位。站点上往往同时存在多层缓存，只清一层，用戶和抓取端拿到的版本就可能不一致。
先分清站点上的几层缓存
缓存不是單一開關，而是從浏览器到源站的多個环节。排查时先列清楚，再决定刷新顺序。
- 浏览器缓存：用戶本地儲存的舊版頁面和静態文件，受 Cache-Control、Expires 等响應头影响。
- CDN 邊缘缓存：节点上儲存的副本，命中後直接返回，源站更新不一定立刻生效。
- 反向代理與頁面缓存：Nginx、Varnish 或應用自带的頁面缓存，常按 URL 或缓存键儲存整頁 HTML。
- 應用层缓存：對象缓存、查询缓存、片段缓存等，内容更新後如果键没失效，前台仍可能讀舊資料。
這些层各有失效方式，只清 CDN 而不管應用缓存，或者只清首頁而不管列表頁，都會留下舊内容。
發布後的刷新與核對步骤
把刷新当作發布流程的一步，按從内到外的顺序處理，减少遗漏。
- 發布内容，记錄本次修改的 URL、栏目和關联頁面。
- 先清應用层缓存，再清反向代理或頁面缓存，最後刷 CDN。
- 用無痕窗口、不同網絡环境和移動端分別訪問，排除本地缓存干扰。
- 查看响應头中的缓存标识，確認缓存是否命中、過期時間是否合理。
- 观察一段時間，確認詳情頁、列表頁、首頁和 feed 同步更新。
缓存键和版本号別忽略
静態资源可以加 hash 或版本号，让新文件走新地址，避免用戶一直用舊文件。HTML 頁面如果缓存時間设得很長，更新後用戶可能長時間看到舊内容；對更新频繁的栏目，可以設定較短缓存或协商缓存。移動端和桌面端如果内容不同，缓存键要能区分，避免互相覆盖。登入態頁面、用戶中心等带個人信息的頁面，不應被公共缓存長期儲存。
几個容易踩的坑
- 只刷了首頁，栏目頁和詳情頁還在舊缓存里。
- 只清了 CDN，應用层頁面缓存没有動。
- 登入態頁面被公共缓存，導致用戶看到不该看到的信息。
- 缓存過期時間设得很長，又没有主動刷新入口。
- 定时生成静態頁的任務失敗，但没人發現，頁面一直是舊的。
缓存刷新不是發布後的附加動作，而是發布流程的一部分。把“谁刷、刷什么、怎么驗”寫清楚，比事後到處找原因省事。
把刷新動作寫進發布清單
每次更新前，確認本次涉及哪些 URL、哪些栏目、是否影响列表和首頁。發布後由执行人完成刷新，再由另一人抽查。如果站点有回滚机制，回滚时也要同步處理缓存，避免舊版本和新版本混在一起。记錄刷新時間、操作人和驗證结果，方便下次排查。
缓存策略會随内容节奏變化。更新频率高的栏目可以缩短缓存時間，稳定頁面可以适当放長。關键是让用戶和抓取端拿到一致、可预期的版本，而不是让舊頁面長期顶在前面。