核心思路
CDN 在全球布了很多边缘节点，把静态内容缓存到离用户近的地方，源站只需服务一次，之后就近返回，延迟和源站压力都下降。
请求怎么到边缘
- 用户访问
cdn.example.com，DNS 根据用户位置返回最近的边缘 IP； - 边缘命中缓存直接返回；
- 未命中则回源站取，缓存后再返回。
缓存的两个动作
| 动作 | 作用 |
|---|---|
| 刷新（purge） | 删掉旧缓存，强制下次回源拿新版 |
| 预热（prefetch） | 主动把内容推到边缘，避免首访冷启动 |
什么适合上 CDN
- 适合：图片、脚本、样式、字体、视频等静态资源；
- 不适合：含用户隐私的动态内容（会串给用户），这类应加
Cache-Control: private或走源站。
边缘逻辑与缓存键设计
现代 CDN 不只是缓存，还能在边缘执行逻辑。用得好能显著降低源站压力，用得不好会制造难以复现的问题：
- 缓存键要显式定义：默认键通常只含 URL，若响应随语言、设备或登录态变化，必须把这些维度纳入键，否则会把 A 用户的内容发给 B；
- 查询串处理：无关参数（如营销跟踪参数）应被忽略以减少缓存碎片，而真正影响内容的参数必须保留；
- 边缘逻辑保持简单：重定向、鉴权转发、A/B 分流适合放在边缘；复杂业务逻辑放在边缘会带来调试困难与版本漂移；
- 回源保护：配置回源超时、重试次数与并发上限，避免源站抖动时被 CDN 的重试放大成雪崩；
- 缓存预热与刷新：大促或发版前主动预热热点内容，并对变更内容做定向刷新，而不是全量清空。
另外要明确“哪些内容允许缓存”：把 Vary、Cache-Control 当作契约的一部分写进接口规范，而不是上线后凭经验补。
故障排查与容量视角
- 先确认命中来源：排查时先看响应头中的缓存状态，判断内容来自边缘还是回源。若持续回源，问题多半在缓存键或缓存声明，而不在源站性能。
- 留意地域差异：同一份内容在不同区域表现不同，通常意味着部分节点未预热或回源链路质量不一。应按区域观察指标，而不是只看全局平均。
- 容量与带宽峰值：提前评估活动带来的带宽峰值，并确认套餐或计费模式能否覆盖，避免流量突增时因限额被限速。
- 回源集中风险：缓存大面积失效会让请求瞬时全部回源，形成对源站的冲击。应对失效操作做分批与限流，或在低峰期执行。
- 配置变更要有回滚：缓存规则与边缘逻辑的变更应保留上一版本并能快速切回，配置错误的影响范围往往比代码错误更大。
把 CDN 当作需要容量规划与变更管理的系统来对待，而不是一次配好就不管的静态资源通道，是长期稳定的前提。