内容更新发布后，后台显示已保存，前台访问却还是旧版本。这种情况不一定发布失败，很多时候是缓存没有刷新到位。站点上往往同时存在多层缓存，只清一层，用户和抓取端拿到的版本就可能不一致。
先分清站点上的几层缓存
缓存不是单一开关，而是从浏览器到源站的多个环节。排查时先列清楚，再决定刷新顺序。
- 浏览器缓存：用户本地保存的旧版页面和静态文件，受 Cache-Control、Expires 等响应头影响。
- CDN 边缘缓存：节点上保存的副本，命中后直接返回，源站更新不一定立刻生效。
- 反向代理与页面缓存：Nginx、Varnish 或应用自带的页面缓存，常按 URL 或缓存键保存整页 HTML。
- 应用层缓存：对象缓存、查询缓存、片段缓存等，内容更新后如果键没失效，前台仍可能读旧数据。
这些层各有失效方式，只清 CDN 而不管应用缓存，或者只清首页而不管列表页，都会留下旧内容。
发布后的刷新与核对步骤
把刷新当作发布流程的一步，按从内到外的顺序处理，减少遗漏。
- 发布内容，记录本次修改的 URL、栏目和关联页面。
- 先清应用层缓存，再清反向代理或页面缓存，最后刷 CDN。
- 用无痕窗口、不同网络环境和移动端分别访问，排除本地缓存干扰。
- 查看响应头中的缓存标识，确认缓存是否命中、过期时间是否合理。
- 观察一段时间，确认详情页、列表页、首页和 feed 同步更新。
缓存键和版本号别忽略
静态资源可以加 hash 或版本号，让新文件走新地址，避免用户一直用旧文件。HTML 页面如果缓存时间设得很长，更新后用户可能长时间看到旧内容；对更新频繁的栏目，可以设置较短缓存或协商缓存。移动端和桌面端如果内容不同，缓存键要能区分，避免互相覆盖。登录态页面、用户中心等带个人信息的页面，不应被公共缓存长期保存。
几个容易踩的坑
- 只刷了首页，栏目页和详情页还在旧缓存里。
- 只清了 CDN，应用层页面缓存没有动。
- 登录态页面被公共缓存，导致用户看到不该看到的信息。
- 缓存过期时间设得很长，又没有主动刷新入口。
- 定时生成静态页的任务失败，但没人发现，页面一直是旧的。
缓存刷新不是发布后的附加动作，而是发布流程的一部分。把“谁刷、刷什么、怎么验”写清楚，比事后到处找原因省事。
把刷新动作写进发布清单
每次更新前，确认本次涉及哪些 URL、哪些栏目、是否影响列表和首页。发布后由执行人完成刷新，再由另一人抽查。如果站点有回滚机制，回滚时也要同步处理缓存，避免旧版本和新版本混在一起。记录刷新时间、操作人和验证结果，方便下次排查。
缓存策略会随内容节奏变化。更新频率高的栏目可以缩短缓存时间，稳定页面可以适当放长。关键是让用户和抓取端拿到一致、可预期的版本，而不是让旧页面长期顶在前面。