CDN刷新 vs 预热区别

CDN刷新是让旧缓存失效，预热是提前把资源缓存到 CDN 节点。刷新用于资源更新、清理旧内容；预热用于活动上线、大文件发布前提前降低源站压力、提升首次访问体验。

---

对比

对比项	CDN 刷新	CDN 预热
核心目的	清除或失效 CDN 上的旧缓存	提前把资源拉取并缓存到 CDN
触发方向	用户访问时，CDN 回源获取新内容	CDN 节点主动回源拉取资源
典型场景	文件更新、页面改版、违规资源清理、配置变更	活动前、安装包发布前、热点资源提前加载
支持对象	URL、目录、正则刷新	只支持具体 URL，不支持目录预热
对源站影响	刷新后用户访问会集中回源，可能增加源站压力	预热时会提前产生回源流量，降低高峰期压力
是否立即全网命中	不是，刷新任务通常需几分钟生效	不是，通常主要预热到 L2 回源节点，L1 仍依赖用户访问逐步缓存

什么时候用刷新

当你希望旧内容不要再被用户访问到时，用刷新。

常见情况包括：源站资源已经更新，但 CDN 还缓存旧版本；网站页面、图片、JS、CSS 发布了新版本；删除了源站上的不合规资源，但 CDN 节点仍可能缓存；修改了缓存规则、回源配置、响应头配置后，希望 CDN 重新获取最新结果。如果只是普通静态资源发布，URL 刷新通常更精确。如果是整个目录下资源都变更，可以用目录刷新。如果需要按文件类型、版本号、路径模式批量处理，可以使用正则刷新。不过正则刷新配额更少，应谨慎使用。

什么时候用预热

当你希望用户访问之前 CDN 已经准备好资源时，用预热。

典型场景是大型活动上线前，把活动页涉及的核心静态资源提前预热；新版本 App 安装包、视频、大文件发布前，提前把文件预热到 CDN；首次接入 CDN 后，将热点静态资源提前缓存，减少首次访问延迟。预热更适合大文件、热点文件、关键资源。大量小文件通常不建议全部预热，因为预热会产生回源流量，且默认每日 URL 预热配额有限。

使用建议

发布新版本时，通常先更新源站资源，再刷新 CDN 缓存。如果是同名文件覆盖发布，尤其是 HTML、JS、CSS 这类容易被缓存影响的资源，最好结合版本号或文件 hash，例如 app.a1b2c3.js，减少强制刷新依赖。

活动或大文件上线前，建议提前 5 到 30 分钟做预热，并在低峰期执行，避免预热本身造成源站压力。预热完成后，可以用 curl -I <资源链接> 查看响应头，如果 X-Cache 为 HIT，通常表示命中缓存；如果是 MISS，说明可能尚未完成或预热失败。

简而言之：内容变了，用刷新；流量要来了，用预热；同名文件强更新，优先考虑强制刷新；大文件活动上线，优先考虑预热。