站点运营里有一类问题很隐蔽：后台明明改完了，图片换了、价格改了、条款更新了，访客截图发过来却是旧版本。多数时候不是服务器没更新，而是缓存在中间层把旧内容继续发了出去。缓存本身是好事，它能让页面更快、让源站压力更小，但如果缺少刷新与验证机制，它就会变成“看不见的旧版本仓库”。
先弄清缓存落在哪几层
排查之前，先知道一份页面从源站到访客浏览器之间会经过哪些环节。不同层级的失效方式不一样，只看其中一层很容易误判。
- 浏览器缓存：由响应头里的 Cache-Control、Expires、ETag 控制，只影响单个访客。
- CDN 边缘节点：内容被复制到各地节点，回源频率由缓存规则决定。
- 反向代理与 Web 服务器缓存：如 Nginx 的 proxy_cache、fastcgi_cache。
- 应用层缓存：页面缓存、片段缓存、对象缓存，常见于内容管理系统。
- 数据库与查询缓存：结果被暂存，数据更新后未必立刻反映。
同一个“页面没更新”的现象，可能来自其中任意一层，也可能是几层叠加。
静态资源与 HTML 要区别对待
最常见的配置错误，是把 HTML 和图片、CSS、JS 用同一套缓存规则。前者内容会变，后者通常靠文件名版本号来区分。
- 带指纹或版本号的静态资源，可以设置很长的缓存时间，更新时换文件名即可。
- HTML 页面缓存时间不宜过长，或使用协商缓存，让浏览器每次回来问一句。
- 接口返回的数据要单独评估，尤其是价格、库存、登录状态相关内容。
- 别对带用户信息的页面做公共缓存，否则可能把 A 的信息发给 B。
缓存键设置得越细，命中率越低
缓存键决定了“什么样的请求算同一个页面”。如果键里包含了多余的参数、Cookie 或设备标识，命中率会骤降，源站压力反而上升；反过来，键里漏掉了影响内容的维度，就会出现串内容的尴尬。
常见做法是：忽略无意义的跟踪参数，保留真正影响输出的语言、地区、终端类型等维度。改完规则后，用不同参数多请求几次，确认返回内容符合预期。
更新发布时，刷新顺序很重要
一次改动往往涉及多层缓存，顺序错了就会出现“新的 HTML 配旧的 CSS”这类错位情况。
- 先发布源站内容，确认源站直连访问得到的是新版本。
- 再刷新 CDN 上与本次改动相关的 URL，必要时按目录或标签刷新。
- 接着清理应用层与对象缓存，避免页面模板已经更新、数据仍是旧的。
- 最后处理浏览器端，靠版本号或文件名变更让访客拿到新资源。
- 发布后对着关键页面做一轮抽查，而不是只看首页。
几招快速验证缓存是否生效
- 用命令行查看响应头，关注 Age、Cache-Control、X-Cache 之类的字段，判断请求是否命中节点。
- 用无痕窗口或换一个网络环境访问，排除本地缓存干扰。
- 抓不同地区的节点，或借第三方工具，确认各地返回一致。
- 看访问日志里 304 与 200 的比例，比例异常往往说明缓存策略有问题。
- 发布后固定抽查几个高频入口页，比等到用户反馈要省事得多。
缓存不是“设完就忘”的功能，它是需要跟着发布流程一起走的一环。把它写进上线检查清单，比事后逐层排查轻松得多。
把它变成日常习惯
不需要每次发布都全量刷新，但需要有一份明确的规则：哪些内容必须即时生效，哪些可以容忍几分钟延迟；谁负责刷新，刷新后怎么验证。把这些写下来，新同事接手时就不会只改文件、不刷缓存。站点运营的很多麻烦，本质上都是流程缺了一小步，而不是技术做不到。