运营同事跑过来投诉：首页banner换了半小时了，怎么打开还是旧的？我去查了一下，源站内容早就更新了，但CDN边缘节点还缓存着老版本。用户看到的是旧内容，这就是典型的CDN缓存一致性问题。这个问题在小团队里特别常见，因为内容更新和缓存管理往往是两拨人。
为什么缓存会不一致
CDN的核心逻辑是就近缓存。用户请求到边缘节点，如果节点上有缓存就直接返回，没有才回源站取。这个机制在静态资源上工作得很好，但内容一旦更新，旧缓存不会自动消失，要等TTL过期才会重新回源。
问题就出在这个时间差上。TTL设短了，缓存命中率低，回源压力大；TTL设长了，内容更新不及时。本质上是缓存效率和数据一致性之间的权衡。
三种缓存同步策略
主动刷新是最直接的方式。内容更新后主动调CDN的刷新接口，把指定URL或目录的缓存清掉。下次用户请求时边缘节点会回源拉新内容。各大CDN厂商都提供这个API，可以跟发布流程集成——代码部署完自动触发刷新。
但主动刷新有局限：全球几百个边缘节点，刷新传播需要时间，通常几秒到几分钟不等。如果用户正好在刷新前命中了旧缓存，还是会看到旧内容。
缓存预热是刷新的升级版。不只是清掉旧缓存，而是主动把新内容推送到所有边缘节点。这样用户请求时直接命中新缓存，不需要回源。适合发布重要内容、版本更新这种必须立刻全量生效的场景。预热接口大部分CDN也支持，但有的按次数收费，提前了解好计费规则。
版本化URL是治本之策。给每个资源带上版本号或hash，比如app.v2.3.js、logo_a3b7c.png。内容更新时改文件名，HTML里引用新路径，CDN对新URL没有缓存，自然回源拿新内容。旧URL的缓存让它自然过期就行，不用主动刷。这种方式彻底绕开了一致性问题，缺点是发布流程要改造，构建工具需要自动生成带hash的文件名。
怎么选
日常内容更新（文章、商品信息），用主动刷新就够了，配好发布钩子自动化执行。
重大版本发布、首页改版，刷新加预热双保险。
前端静态资源（JS、CSS、图片），上版本化URL，一劳永逸。
还有一个小技巧：对频繁更新的内容，TTL设成300秒（5分钟）是个比较平衡的值——即使忘了刷新，最多5分钟后用户也能看到新内容。这算是兜底策略，跟数据迁移备份一个思路：不能只靠一道防线。