做站点运营时，最容易忽略的一类问题不是页面写错了，而是页面改了却没人看到。你把标题、正文、价格都更新了，访客看到的还是旧版本，抓取工具拿到的也是旧版本。这往往不是发布失败，而是缓存没有处理好。缓存本身是好东西，它能降低服务器压力、加快首屏速度，问题在于缺少规则和验证。
先搞清楚改的是哪一层缓存
一次请求从浏览器到源站，可能经过好几层缓存。定位问题时，先把层次分清楚，比盲目刷新有效得多。
- 浏览器缓存：由 Cache-Control、Expires 等响应头控制，缓存在访客本地，你无法远程清理。
- CDN 或反向代理缓存：缓存在边缘节点上，同一地区用户可能共享同一份内容。
- 应用层缓存：页面缓存、对象缓存、数据库查询缓存，常见于动态站点和框架层。
- 服务端脚本缓存：如 PHP 的 OPcache、模板编译缓存，改动后需要确认是否自动失效。
自查清单：更新之后要确认的几件事
1. HTML 文档不要设置长缓存
HTML 是内容的入口，建议使用较短的 max-age，或者 no-cache 配合 ETag、Last-Modified，让浏览器每次回源做一次校验。真正适合长缓存的，是带版本指纹的 CSS、JS 和图片。
2. 静态资源用文件名指纹
修改样式或脚本时，同时更改文件名或加 hash 后缀，例如 style.3f9a2.css。这样旧文件可以继续被缓存，新文件自然走新地址，不必依赖人工刷新节点。
3. CDN 缓存规则按目录和类型区分
- 文章详情页：可以缓存几分钟到几十分钟，并允许回源校验。
- 首页和频道页：按更新频率设置较短缓存，避免长期停在旧版本。
- 登录态、购物车、后台入口：不缓存，或按 Cookie 绕过缓存。
- 带参数的地址：确认规则是否忽略无关参数，别让每个跟踪参数都生成一份独立缓存。
4. 主动刷新要有记录
发布之后，明确知道需要刷新哪些 URL，并尽量通过接口批量提交，把刷新动作写进发布流程。靠“等一会儿再看看”容易漏掉关键页面。
一个可执行的验证流程
- 用无痕窗口打开页面，排除本地缓存干扰，确认内容是否为最新。
- 在开发者工具的 Network 面板查看 HTML 响应头，关注 Cache-Control、Age、ETag 以及 CDN 返回的命中标识。
- 换一个网络环境或不同地区节点再请求一次，确认边缘节点也已更新。
- 检查带参数的地址是否返回同样的内容，避免参数版本停留在旧页。
- 查看最近的抓取记录，确认抓取工具拿到的版本与后台一致。
缓存和内容更新之间的关系
抓取工具看到的是它抓取那一刻的版本。如果边缘节点长期返回旧页面，抓取结果就和后台内容不一致，更新可能很久都不被反映。所以缓存策略不只是性能问题，也关系到内容更新能否被及时发现。
常见误区
- 把“清缓存”当成万能药，每次改动都全站刷新，反而让缓存失去意义。
- HTML 和静态资源套用同一套长缓存规则。
- 只在本地测试，忽略了 CDN 边缘节点的状态。
- 移动端和桌面端共用缓存键，导致一端看到另一端的页面。
- 忘记给 404、301 这类响应设置合适的缓存，让错误结果被长期记住。
把缓存写进发布清单
建议在每次内容发布或改版前，固定回答几个问题：本次改动了哪些 URL；这些 URL 经过哪几层缓存；是否需要主动刷新；刷新之后用什么方式验证。把答案记录下来，缓存就从一件凭感觉的事，变成流程里可以检查的一环。缓存的目标从来不是让内容永不更新，而是在响应速度和内容新鲜度之间找到合适的平衡点。