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