内容已经发布，访客却说“还是老样子”；后台数据改了，前台价格没变；运营同学反复刷新，只有自己电脑上是新的。遇到这类反馈，先别怀疑发布流程，多半是缓存没刷新。缓存本身不是问题，问题在于我们不知道内容卡在哪一层、该在哪里清。
先把缓存的层数分清楚
一个页面从服务器到访客屏幕，中间可能经过好几层缓存。排查之前，先列清楚自己的站点有哪些：
- 浏览器缓存：访客本地保存的副本，由响应头里的 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，方便下次遇到类似问题时对照。
缓存做得对，站点会更快、更稳；做得糊涂，就会变成“我这边好了，别人那边没变”的反复拉扯。把每一层缓存的位置、策略和刷新入口写进运维记录，比临时找人清缓存要可靠得多。