团队一旦接入 CDN，往往会默认“性能问题已经解决一半”。
真实情况常常相反：
- 页面偶尔很快，偶尔又非常慢
- 缓存命中率看上去不错，关键页面却仍然频繁回源
- 动态页面、登录态页面和静态资源的策略互相打架
这说明真正的问题不在“有没有 CDN”，而在“缓存规则是否稳定、可预测”。
CDN 优化的关键不是缓存更多，而是缓存得更准
缓存命中本身不是目标，稳定命中才有价值。
如果缓存键设计错误，即使名义上开启了边缘缓存，也可能出现：
- 同内容被重复缓存多份
- 某些请求永远命不中
- 用户拿到不该共享的内容
所以 CDN 配置首先是规则设计问题，而不是开关配置问题。
先把资源按可缓存程度分层
更稳的做法是把资源拆成三类：
- 强静态资源：版本化 JS、CSS、图片、字体
- 可短时缓存的页面或接口：列表页、详情页、聚合内容
- 不可共享或需谨慎缓存的动态内容：登录态、个性化结果、敏感接口
只有分层明确后，边缘策略才不会互相污染。
缓存键设计决定命中率上限
很多命中率不稳定的问题，不是资源本身不可缓存，而是缓存键维度太多。
常见问题包括：
- 无关 query 参数进入缓存键
- 过多 cookie 参与区分
- A/B 实验或地区标识没有统一归一化
更有效的思路通常是：
- 明确哪些参数影响内容
- 其余参数在边缘层做忽略或归一化
- 对多版本内容建立有限、明确的变体规则
动态页面也不是完全不能吃到边缘收益
不少团队把 CDN 只用于静态资源，动态页面完全放弃边缘优化。
其实很多内容页、列表页和 SSR 页面都可以通过以下方式获得收益：
- 边缘短缓存
- stale-while-revalidate
- 按内容版本或发布时间做缓存失效
- 在服务端拆分共享片段与个性化片段
关键不是页面是否动态，而是哪些部分真的需要实时个性化。
常见失败案例：清缓存成了日常操作
如果团队经常靠手动 purge 来维持页面正确，大概率说明缓存设计存在结构问题。
原因通常包括：
- 资源没有版本号
- 页面失效策略依赖人工操作
- 回源链路没有稳定分层
- 运营更新与缓存刷新脱节
手动清缓存可以救急，但不能作为长期机制。
一个更稳的边缘治理方式
推荐的思路通常是：
- 先定义资源分类与缓存时长策略
- 清理无意义的缓存键维度
- 为动态页面建立短缓存和再验证机制
- 用版本号和内容更新时间驱动失效
- 监控命中率、回源率与热点波动
只有这样，CDN 才会成为稳定收益，而不是偶发加速器。
一份可直接复用的检查清单
- 是否先完成了资源与页面的缓存分层
- 缓存键是否只保留真正影响内容的维度
- 动态页面是否设计了短缓存或再验证机制
- 是否通过版本化和规则化失效减少手动 purge 依赖
- 是否持续监控命中率、回源率和热点波动
总结
CDN 与边缘缓存优化的核心，不是把更多请求塞进缓存，而是让缓存命中稳定、可预测、可维护。只要资源分层、缓存键治理和失效策略一起设计，边缘收益才会持续放大。
进一步阅读：
