内容更新上线后，最容易出现的一种错觉是：后台已经发布，编辑自己刷新也看到了新版本，就默认所有人都看到了。实际上，访客、蜘蛛、不同地区的用户，可能还在从浏览器缓存或 CDN 边缘节点读取旧页面。缓存本身不是坏事，它让站点更快、更稳、更省钱，问题在于更新时没有把缓存的边界和清理顺序想清楚。
先分清有哪几层缓存在起作用
一个请求从用户到源站，通常会经过多层缓存。排查“为什么还是旧内容”时，按层往下找，比反复点发布按钮有效。
- 浏览器缓存：用户设备上的副本，受 Cache-Control、Expires、ETag 等响应头控制。
- CDN 边缘缓存：离用户最近的节点缓存，命中后可能完全不回源站。
- 反向代理与页面缓存：Nginx、Varnish、部分 CMS 插件生成的静态化页面。
- 对象存储与附件缓存：图片、CSS、JS、下载文件的缓存。
这几层的过期时间往往不一样。静态资源可以设很长，HTML 页面通常不适合设太长，否则发布后要等很久才生效。
更新后该清理哪些地址
很多人只清了首页，结果栏目页、列表页、标签页还是旧内容。建议把需要刷新的地址分成几组：
- 本次直接改动的详情页。
- 会引用它的列表页、栏目页、首页。
- 站点地图、RSS、搜索结果页等自动生成页面。
- 带版本号或指纹的静态资源，如果文件名没变，也要一起刷新。
清理顺序建议是：先确认源站已经更新，再清 CDN，最后通知浏览器重新验证。如果源站还没更新就清 CDN，边缘节点回源拿到的仍然是旧内容。
缓存键决定了命中范围
缓存键不只是 URL。查询参数、Cookie、请求头、设备类型、地区都可能参与缓存键。参数越多，缓存命中率越低；参数太少，又可能把不该缓存的内容混在一起。
- 带登录态的页面不要做公共缓存，否则可能把 A 用户的信息给到 B 用户。
- 筛选、排序、分页参数如果会出现在缓存键里，要评估是否需要缓存，避免生成大量低价值缓存副本。
- Vary 头设置不当，可能让同一个地址在缓存里裂成很多份。
比较稳妥的缓存策略
静态资源（带内容指纹的 CSS、JS、图片、字体）可以设置较长缓存，文件名变化时自然更新。HTML 页面更适合短缓存加协商缓存，让浏览器和 CDN 在过期后回源验证。
列表页和首页更新频繁，缓存时间可以比详情页更短，或者发布时主动刷新。sitemap、RSS 这类文件如果被长时间缓存，可能影响新内容的发现，建议使用较短的缓存时间，并在更新后主动清理。
缓存的目标不是“永远不缓存”，而是让该快的快、该新的新。更新流程里如果没有缓存刷新这一步，就等于把缓存当成了不可控变量。
别为了蜘蛛抓取把缓存整体关掉
有时会发现蜘蛛抓到的还是旧页面，于是干脆关闭 CDN 缓存。这样做短期看似解决问题，长期会让源站压力上升、响应变慢，反而影响抓取效率。更合理的做法是：给 HTML 设置合理短缓存，保证蜘蛛多次访问时能拿到较新版本；同时通过 sitemap、内链和主动提交，让新地址更快被发现。
蜘蛛是否抓到新内容，受抓取频率、页面权重、缓存时间共同影响。缓存只是其中一个因素，不要把它当成唯一开关。
一份可以照着做的自查清单
- 发布后抽查首页、栏目页、详情页，确认源站和 CDN 返回一致。
- 用 curl -I 或浏览器开发者工具查看 Cache-Control、Age、X-Cache 等响应头。
- 确认 sitemap、RSS 没有被长时间缓存，更新后能立即反映新地址。
- 检查带登录态、带用户信息的页面是否误做公共缓存。
- 观察回源量和 5xx 错误，避免缓存过期集中在同一时间造成回源尖峰。
- 把“刷新缓存”写进发布流程，而不是靠记忆临时操作。
缓存配置不需要一次做到完美，但需要有一条清晰的更新链路：源站先变，缓存后清，最后验证。把这几步固定下来，内容更新后“别人看到的还是旧页面”这类问题会少很多。