清除CDN缓存完全指南：原理、操作方式与刷新后排错
改了一个样式文件、换了一张图片、修了一句文案，自己电脑上刷新一切正常，但同事和用户的截图里还是老样子。这种情况十有八九不是源站没更新成功，而是 CDN 边缘节点上仍存着旧的那一份副本。清除 CDN 缓存（日常也常被叫作“刷新缓存”“刷 CDN”）做的事其实很简单：通知分布在各地区的边缘节点丢掉指定内容，让下一次请求重新回到源站取一份新的。
看上去只是点一个按钮，实际做起来却有不少讲究：清哪些地址、清多大范围、清完之后为什么还有人看到旧内容、怎样确认真的清干净了。这些问题如果没想清楚，就容易陷入“反复刷新但用户依旧报错”的循环。
一、先弄明白：CDN 缓存里究竟存了什么
边缘节点、回源与命中率
CDN 的运作方式是把源站内容复制到离用户更近的节点上。用户第一次请求某个文件时，节点手里没有，就会回源站取回一份放进自己的缓存，同时返回给用户；之后再有用户请求同一个文件，节点直接把手里的副本返回，不再打扰源站。这就是缓存命中与回源的区别。命中率越高，源站压力越小、响应越快，但也意味着节点里的副本与源站之间存在一个“时间差”。
TTL 决定节点何时自愿放手
节点什么时候主动丢弃副本，由 TTL 决定。TTL 可能来自源站响应头里的 Cache-Control: max-age 或 s-maxage、Expires，也可能来自 CDN 控制台上按文件类型、按目录配置的缓存规则。在 TTL 到期之前，节点默认相信自己手里的副本是正确的，不会回源核对。于是出现典型场景：源站早就改好了，节点上还是旧的，用户看到的也就是旧的。
缓存键决定“清得对不对”
决定哪一份内容被缓存的是缓存键。多数 CDN 默认把完整 URL（含查询字符串）作为缓存键，也有一些配置会忽略查询参数、忽略协议、统一大小写。缓存键怎么定义，直接决定了清除时要清哪个地址：如果配置忽略了 ?v=1 这类参数，那么带参数和不带参数的地址实际上是同一条缓存；反过来，如果参数参与缓存键，只清不带参数的地址就清不掉带参数的版本。动手之前先在控制台确认缓存键规则，能省掉很多无效刷新。
二、哪些场景确实需要清除缓存
清除缓存成本不高，但也不是零成本：每一次刷新都可能带来一波回源请求，源站要接得住。因此判断标准应当明确——要么必须让旧内容立刻消失，要么必须让新内容立刻出现。
- 紧急下线：页面、图片、视频或安装包里出现错误、敏感或不合规内容，需要立刻不可访问。
- 同名覆盖：文件名没变、内容换掉了，例如替换了头像、更新了 PDF、修了 JavaScript 里的一行逻辑、改了 logo。源站是新的，节点还是旧的。
- 配置变更：缓存 TTL、缓存键、防盗链、回源协议等规则调整后，希望新规则立刻作用在已缓存的文件上。
- 源站迁移：从对象存储迁到自有服务器，或更换了源站地址，旧副本里可能还引用着旧域名的资源。
- 上线后样式错乱：HTML 已更新，而它引用的 CSS、JS、字体仍是旧版本，页面结构对不上。
- 误发内容撤回：测试页面、未脱敏数据被发布到了公开地址。
反过来，如果只是新增了一个从没被访问过的文件，或者文件本身带内容指纹（例如 app.7f3c9a.js），旧文件不会再有人请求，清不清除意义不大，等它自然过期即可。
三、清除 CDN 缓存的几种方式
1. 按 URL 刷新：最精准，优先选择
把需要更新的完整地址逐条提交，包括协议、域名、路径和查询参数，只清这几条缓存。优点是影响面小、回源压力可控，适合发布少量文件或紧急修正单页内容。缺点是地址多时要一条条整理，容易漏掉关联资源——页面更新往往牵动 HTML、CSS、JS 和图片，最好提前把清单列全。注意 URL 必须与用户实际请求的地址完全一致，编码方式、大小写、末尾是否带斜杠都可能造成“提交成功但没清到”。
2. 按目录刷新：省事，但要留意边界
提交一个目录路径，该目录下的缓存一并清除。适合整站改版、某个栏目的静态资源批量更新。使用时要搞清楚服务商的匹配规则：是否递归包含子目录、是否需要以斜杠结尾、是否只匹配该前缀。目录写得过宽（例如直接填根目录）实际上等同于全站刷新，回源压力会明显上升。
3. 全站刷新与正则、前缀刷新：慎用
全站刷新会把所有缓存内容标记为失效，下一个请求全部回源。对大流量站点来说，这是一次小型的“回源洪峰”，如果源站带宽或数据库承受能力有限，可能引发响应变慢甚至短暂不可用。正则刷新则更灵活也更危险，写错一个字符就可能清掉大量不该动的文件。除非是严重的内容事故，一般不建议把全站刷新当作日常手段。
4. 通过 API 把刷新接进发布流程
手动在控制台点按钮，只适合零星操作。稳定的做法是把缓存刷新接到发布流水线里：构建产物上传完成后，由脚本调用服务商提供的刷新接口，提交本次变更的 URL 列表，并把结果写入发布日志。这样既避免了“忘了刷”的人为疏漏，也让每次刷新都有据可查。回滚时同样执行一遍刷新，保持源站与边缘节点一致。
四、各家 CDN 的操作入口在哪
不同服务商的叫法不完全一样，有的叫“缓存刷新”，有的叫“purge”，有的把 URL 刷新和目录刷新分成两个入口，但逻辑相通：都在控制台找到缓存管理相关页面，选择刷新类型、提交地址、等待任务完成。常见的几家可以参见 Cloudflare（Purge Cache，支持按 URL、按标签、全站清除）、Amazon CloudFront（Invalidation）、Akamai，以及国内的 阿里云 CDN、腾讯云 CDN、七牛云、又拍云等。选择时除了看刷新方式，也要关注刷新配额、任务下发速度、是否支持按标签或缓存标签批量清除。
五、刷新之后仍是旧内容？按顺序排查
浏览器本地缓存与协商缓存
最常见的原因是用户自己的浏览器还留着副本，与 CDN 无关。强缓存未过期时浏览器根本不会发请求；协商缓存则会带上 If-None-Match 或 If-Modified-Since，服务端返回 304 后继续使用本地副本。让用户强制刷新（Ctrl/Cmd + Shift + R）、开无痕窗口，或者直接换一台设备测试，能快速区分是 CDN 问题还是本地问题。
Service Worker 与前端离线缓存
注册过 Service Worker 的站点，静态资源可能被浏览器端的缓存策略接管，即使 CDN 已经更新，页面读到的仍是本地缓存。排查时可以在开发者工具的 Application 面板里注销 Service Worker 并清空 Cache Storage。发布新版本时给缓存名称加上版本标识，也能减少这类困扰。
多节点、多地域与多线路
刷新任务下发到全部节点需要一点过程，短时间内不同地区用户看到的版本可能不一致。另外，如果站点同时接了多家 CDN、有主备切换，或者前面还挂着一层反向代理、后面的源站自身也有缓存（如对象存储、Nginx proxy_cache、页面缓存插件），那么只清一层是不够的，需要逐层确认。
刷新任务本身的问题
提交的 URL 与真实请求不一致（http 与 https 分开、带 www 与不带 www 分开、参数顺序不同）、超出当日刷新配额导致部分任务失败、目录规则没匹配到目标文件，都会造成“显示提交成功但内容没变”。在控制台的任务记录里核对状态，是最直接的办法。
六、如何确认缓存真的清干净了
不要只靠刷新页面判断。用命令行请求目标地址，观察响应头里的缓存标记，会更可靠：curl -I https://example.com/static/app.css。重点看几个信号——Age 是否归零或很小，说明是刚回源取的新副本；X-Cache、CF-Cache-Status、X-Cache-Lookup、Via 等字段显示 MISS 或已过期；ETag、Content-Length、Last-Modified 是否与源站一致。再从不同网络环境请求几次，确认各节点表现一致，基本就能放心了。
七、与其反复手动清，不如让缓存自动过期
清除缓存本质上是补救手段，真正省心的做法是让缓存策略在发布时自动生效：
- 静态资源加内容指纹：文件名里带哈希，内容一变文件名就变，浏览器和 CDN 自然会去取新文件，旧文件无需清除。
- HTML 短缓存或不缓存：入口文档保持较短的 TTL 或使用 no-cache 配合 ETag，保证用户总能拿到最新引用。
- 静态资源长缓存：带指纹的 JS、CSS、图片可以设置很长的 TTL，命中率高又不怕过期问题。
- 善用 stale-while-revalidate：让节点在后台更新副本的同时先返回旧内容，兼顾体验与新鲜度。
- 发布后预热：刷新之后主动请求主要页面和核心资源，把新副本提前推到节点上，避免第一批真实用户承担回源延迟。
八、操作清单：清除 CDN 缓存前后的注意事项
- 动手前先确认源站内容已生效，否则清完缓存取回的仍是旧内容，白忙一场。
- 尽量用 URL 刷新替代全站刷新，范围越小，回源冲击越可控。
- 列全关联资源：HTML、CSS、JS、字体、图片、接口返回的静态 JSON 都要覆盖。
- 注意协议与域名的差异，http 与 https、主域名与子域名通常需要分别处理。
- 确认刷新配额与频率限制，批量任务分批提交，并核对每批的执行结果。
- 刷新完成后做一次预热，并记录本次清除的地址清单，方便回滚时对照。
- 把刷新动作写进发布流程和应急预案，明确谁有权发起全站刷新。
清除 CDN 缓存是一项看起来简单、做起来需要章法的运维动作。理解缓存键与 TTL 的作用范围，选择恰当的刷新粒度，配合内容指纹与合理的缓存头设计，绝大多数“用户看到的还是旧内容”的问题都能在发布阶段被提前化解，而不是等到事故出现后再去一个个节点上找原因。
