CDN缓存刷新与预热操作指南
CDN通过缓存机制加速内容分发，但缓存更新不及时可能导致用户看到旧内容。理解CDN的缓存刷新和预热机制，对于内容管理至关重要。本文详解两者的区别、使用场景和最佳实践。
「CDN缓存刷新与预热操作指南」并不是一个孤立的话题。CDN 与边缘加速同时牵动容量规划、网络划分、弹性伸缩与容灾边界等多个层面，只有把它们当作一个整体来推进，才能避免上线之后反复返工、被动救火。
缓存刷新（Purge）
缓存刷新是主动清除CDN节点上的缓存内容，下次用户请求时回源获取最新版本。适用场景：更新了CSS/JS文件、替换了图片、修改了页面内容后，需要让用户立即看到新版本。
操作方式：CDN控制台 → 刷新预热 → URL刷新。支持按URL刷新（精确到单个文件）和按目录刷新（清除某个路径下的所有缓存）。每天刷新配额：URL刷新2000条，目录刷新100个。
最佳实践：静态资源使用版本号（如 app.v1.2.3.js），更新时改变版本号，无需手动刷新缓存。只有动态内容（如首页HTML）才需要主动刷新。
缓存预热（Prefetch）
缓存预热是提前将源站资源拉取到CDN节点，用户首次访问就能命中缓存。适用场景：大版本发布、大促活动前、热门资源上线前。
操作方式：CDN控制台 → 刷新预热 → URL预热。输入需要预热的URL列表，CDN会在后台异步拉取。每天预热配额：URL预热2000条。
注意事项：预热是异步操作，大文件预热可能需要几分钟。预热期间不要刷新同一批URL。预热完成后可以通过"URL检测"功能验证缓存是否已生效。
缓存过期时间配置
在CDN控制台 → 缓存配置中设置不同文件类型的缓存时间：
- 图片（jpg/png/gif/webp）：30天
- CSS/JS：7天（使用版本号管理更新）
- 字体文件（woff/woff2/ttf）：30天
- HTML：10分钟-1小时（根据更新频率）
- 视频（mp4/m3u8）：30天
- API响应：不缓存或缓存10秒
缓存命中率优化
缓存命中率低于90%说明有大量请求回源了。优化方法：延长缓存时间、预热热门资源、检查是否有大量不可缓存的请求（如带Cookie的请求）、开启CDN的"智能缓存"功能。
把CDN 与边缘加速放回架构全局来看
单点的最优解，叠加起来未必是全局最优。评估CDN 与边缘加速时，建议先明确业务的峰值模型与故障容忍度，再倒推资源与网络该怎么设计：哪些负载是稳定基线、哪些是突发流量、哪些可以容忍短暂中断，答案不同，架构取向也完全不同。
在此基础上再谈规格与参数，才有意义。否则很容易陷入「先买资源、再找用途」的被动局面，成本与复杂度都会随之上升。
落地前的自检清单
- 容量与规格：是否用真实压测数据而非经验估算来定规格，是否预留了弹性空间。
- 网络与边界：网段划分是否留有扩展余地，安全组是否遵循最小开放原则。
- 弹性与容灾：扩缩容策略是否经过演练，故障切换路径是否清晰、可回退。
- 可观测性：关键链路是否有指标、日志与告警覆盖，出问题能否快速定位。
这四件事做到位，CDN 与边缘加速才算真正「落地」，而不是停留在方案文档里。