缓存是站点运营里最容易被忽略、又最容易出事故的一环。它平时不声不响，一旦配置不当，访客看到的是几天前的首页，蜘蛛抓到的是一份已经改过的旧内容，客服和运维就会被同一批问题反复轰炸。缓存本身没有错，错的是没人定期看它。
缓存到底缓存了什么
从访客按下回车到页面出现，中间可能经过好几层缓存：浏览器本地缓存、中间的 CDN 或反向代理、应用层的页面缓存与对象缓存、数据库查询缓存。每一层都有自己的过期时间和判断依据，任何一层没对上，结果就会不一致。
自查的目的不是把所有缓存关掉，而是让每层缓存知道自己该存多久、什么时候该失效。对静态资源可以放长一点，对会变动的页面就要短一些，对带用户身份的响应则不该被公共缓存保存。
先看响应头
Cache-Control 是主开关
- max-age：浏览器可以复用的秒数。
- s-maxage：只对 CDN、代理这类共享缓存生效，优先级高于 max-age。
- no-cache：不是不缓存，而是每次使用前必须回源校验。
- no-store：完全不落盘，适合登录态、订单等敏感页面。
- must-revalidate：过期后必须回源，不能拿旧的凑合。
校验头决定回源成本
ETag 和 Last-Modified 让服务器可以用 304 告诉访客“内容没变”，省下重复传输。如果这两个值每次请求都在变，比如时间戳参与了生成，浏览器就永远走全量下载，缓存等于白设。
Vary 别漏
如果站点会根据设备、语言或压缩方式返回不同内容，Vary 头要如实声明。否则共享缓存可能把移动端页面发给桌面访客，或者反过来。
逐层自查怎么做
- 用浏览器开发者工具的 Network 面板查看关键页面的响应头和实际耗时，确认命中的是缓存还是回源。
- 用命令行工具分别请求带与不带缓存头的地址，对比返回体和响应码。
- 在 CDN 后台查看缓存命中率与回源量，命中率过低先查缓存规则是否被某些参数绕过。
- 检查是否存在把带查询参数的地址当成不同资源缓存，导致同一页面被存了很多份。
- 对后台、登录页、支付回调这类地址确认没有被公共缓存保存。
容易被忽视的几个坑
- 发布新版本后只刷新了首页，内页和静态资源仍指向旧文件。
- 给静态资源加了长缓存，文件名却没有指纹或版本号，更新后访客一直拿旧文件。
- 缓存规则写得太宽，把接口返回也缓存了，导致数据滞后。
- 换服务器或换 CDN 后忘记同步旧规则，出现两套策略打架。
- 页面缓存和应用缓存各自为政，清了一处另一处还在生效。
日常维护建议
把缓存策略写进上线流程：改版前先确认影响范围，改版后按资源类型分别处理。可以给静态资源配置带指纹的文件名加长缓存，给 HTML 设置较短的缓存或协商缓存。建立一份缓存规则记录，注明每条规则的路径范围、生效时间和负责人，避免时间久了没人记得为什么这么配。
缓存不是设好就不用管的一次性工作。它和内容更新、服务器变更、CDN 调整绑在一起，任何一处动了，都值得回来看一眼。