CDN 的价值是把内容放到离用户更近的节点上，但如果缓存规则配得过于粗放，就会出现一种很常见的尴尬：源站的页面已经改好，用户和搜索引擎拿到的仍然是几小时甚至几天前的旧版本。缓存本身不是问题，问题在于缓存的时间、范围和失效方式没有跟着内容节奏走。
先分清哪些资源适合长时间缓存
不同资源的更新频率差别很大，用同一套规则去套，通常不是太保守就是太激进。可以先按类型分档：
- 静态资源：带哈希文件名或版本号的 JS、CSS、字体、图片，内容一旦生成就不再变化，适合设置较长的缓存时间。
- 媒体文件：视频、大图、附件，体积大、回源成本高，适合长缓存，但需要注意替换同名文件的场景。
- HTML 文档：栏目页、详情页、首页，内容随时可能调整，缓存时间要短，或者配合主动刷新使用。
- 接口与动态数据：一般不建议在边缘节点长期缓存，除非能接受短暂的数据滞后。
缓存自查清单
1. HTML 文档的 TTL 是否过长
有些站点为了压低源站压力，把 HTML 也设成几小时甚至一天的缓存。结果是编辑改完标题、补完内容，页面在浏览器里刷新还是老样子，只能靠手动刷新缓存救场。如果内容更新较频繁，建议把 HTML 的 TTL 控制在较短区间，或者对首页、栏目页单独设置更短的时间。
2. 缓存键是否把不该合并的 URL 合并了
缓存键决定了哪些请求被视为“同一个页面”。如果规则忽略了全部查询参数，那么带筛选、带排序、带跟踪参数的 URL 都可能命中同一个缓存副本，用户点进不同筛选条件看到的内容却完全一样。反过来，如果把所有参数都算进缓存键，又会生成大量只访问过一次的缓存碎片，命中率大幅下降。常见的折中做法是保留有业务含义的参数，忽略纯跟踪类参数。
3. Vary 头有没有遗漏关键维度
如果站点为移动端和桌面端返回不同的 HTML，却没有在响应头里声明按 User-Agent 区分，就很可能出现移动用户拿到桌面版缓存、桌面用户拿到移动版缓存的情况。压缩方式（Accept-Encoding）通常也需要声明，否则可能出现内容编码错乱。这一项在移动优先的抓取环境下尤其值得检查。
4. 刷新与预热是否覆盖了真正改动的页面
发布内容后，只刷新首页往往不够。列表页、标签聚合页、相关推荐位都可能引用到新内容，需要一并处理。对于重点页面，可以在发布后主动预热，把内容提前推到节点上，避免第一个访问者承担回源等待。
5. 回源策略是否给源站留了余地
当大量缓存同时过期时，请求会集中打回源站，形成短时间的回源高峰。可以关注回源超时时间、重试次数、并发限制这些参数，避免源站在流量尖峰时被自己人打满。源站响应变慢，边缘节点也会跟着变慢，最终体现在抓取和用户体验上。
怎么验证缓存是否按预期工作
- 用命令行工具查看响应头，关注缓存命中状态、缓存年龄、缓存控制字段是否符合预期。
- 从不同地区或不同网络请求同一个 URL，对比返回内容与源站是否一致。
- 挑一个测试页面做小改动，记录各节点更新所需的时间，形成自己的经验值。
- 查看缓存命中率和回源比例，判断规则是否过于保守或过于激进。
- 抽查站点地图中的重点 URL，确认它们返回的是当前版本，而不是历史副本。
几个容易被忽略的细节
刷新缓存不等于内容一定更新。如果源站自身还有一层页面缓存、对象存储副本或模板缓存没有同步，边缘节点回源拿到的依然是旧内容。排查时要顺着链路从源站到边缘逐段确认，而不是只盯着 CDN 控制台。
- 替换同名图片或附件时，长缓存会让旧文件继续被使用，建议改用带版本号的新文件名。
- 站点改版后，旧路径如果被缓存，可能在重定向生效前继续对外服务一段时间。
- 错误页面也可能被缓存。如果某次回源失败返回了错误页，需要确认它不会被当作正常内容长期存放。
小结
缓存策略的目标不是“缓存得越多越好”，而是让每类资源在合适的时间内被复用。把资源分类、TTL、缓存键、Vary 头、刷新与预热这几项过一遍，多数“改了没生效”的问题都能找到出处。