很多站点都遇到过这种情况：后台明明改了标题、换了配图，前台刷新还是旧内容，多点几次、换个浏览器又正常了。这通常不是发布失败，而是缓存没有跟着更新。缓存本身是好东西，它让页面打开更快、回源请求更少，问题是缓存时长和发布流程没有对齐，导致新内容在一段时间里被旧版本挡住。
缓存到底有几层
排查之前先分清对象。常见的缓存至少有三层，刷新页面只能影响其中一部分。
- 浏览器缓存：存在访客本地，由 Cache-Control、Expires 等响应头控制。你自己刷新能看到新内容，别的访客未必。
- CDN 或反向代理缓存：存在边缘节点上，命中之后可能很久不回源。蜘蛛从不同地区抓取时，拿到的也可能是节点上的旧副本。
- 应用层页面缓存：由 CMS 插件或框架生成静态 HTML，后台更新了内容但没清理缓存，页面就一直是旧文件。
自查清单
- 打开几个更新频繁的页面，查看响应头里的 Cache-Control，确认 HTML 的 max-age 是否设得过长。
- 带版本号或文件指纹的 JS、CSS、图片可以设置长期强缓存，HTML 文档不适合照搬这套规则。
- 检查 CDN 的缓存规则是否按路径区分，是否把整站 HTML 都缓存了。
- 确认发布内容后有没有触发缓存刷新，是自动的还是需要人工操作。
- 后台的「清除缓存」按钮是否有人负责按，是否写进了发布流程。
- 缓存过期时间是否和栏目更新频率匹配，日报类栏目和一年不动一次的说明页不该用同一套规则。
- 测试环境与生产环境的缓存是否串味，避免测试内容出现在线上。
缓存问题很少是「设错了某一个值」，更多是没人知道内容更新后该清哪一层。
发布更新的建议顺序
顺序对了可以省掉很多重复刷新：
- 在后台保存并发布内容；
- 清理应用层页面缓存；
- 刷新 CDN 上对应 URL 的缓存，量大时按目录刷新；
- 用无痕窗口或命令行确认线上返回的是新内容；
- 检查地图文件中的最后修改时间是否同步更新。
怎么验证是否命中旧缓存
看响应头最直接：用 curl -I 加上页面地址，重点看 Cache-Control、Age、X-Cache 这类字段。Age 数值很大，说明这份内容在缓存里待了很久；X-Cache 显示 HIT，说明来自节点而不是源站。多节点的情况下，多请求几次或换网络环境再测，结果可能不一样。
哪些内容不适合长缓存
- 登录后的个人页面、购物车、订单页；
- 带用户身份或地域参数的页面；
- 站内搜索结果页；
- 已经确定要下线的旧内容，缓存会让它继续被访问到。
把这些页面单独排除，其余内容再利用缓存提速，才是比较稳的做法。缓存不需要关掉，但需要分层管理，并把「更新后能立刻看到」当成发布流程里的一个固定步骤。