缓存命中率 99% 也可能是坏消息
命中率是被引用最多、也最容易误读的 CDN 指标。它按请求数统计，而账单按字节计算——两者可以指向完全相反的结论。
7 分钟缓存与命中
要点
按请求数算的命中率会被小文件稀释。真正影响账单和体验的是「字节命中率」，两者可以差出几十个百分点。
两个都叫「命中率」的数
几乎所有 CDN 控制台都会给出一个命中率。问题是这个数至少有两种算法，而控制台通常不说自己用的是哪种。
设想一个站点：一万次请求命中了 1KB 的小图标，一次请求未命中 500MB 的安装包。请求命中率是 99.99%，看起来无可挑剔；但未命中的那 500MB 要全额回源，字节命中率不到 5%。账单和源站压力由后者决定，控制台上那个漂亮数字与它们无关。
为什么这件事影响钱
CDN 账单里通常有两笔独立费用：分发流量（CDN 到用户）和回源流量（CDN 到你的源站）。回源单价往往比分发更贵，某些厂商还按回源请求数单独计费。
这意味着字节命中率每降低一个百分点，回源流量就上升一个百分点——而这部分是双倍成本：既付了回源费，又付了源站的出口带宽费。
容易搞错的一点
提高命中率的常见做法是延长 TTL，但对大文件真正有效的往往是分片缓存（Range 支持）。如果厂商不支持分片，一个 500MB 的文件哪怕只被请求了前 1MB，也可能触发整份回源。
怎么自己测
不必依赖控制台。CDN 会在响应头里主动暴露命中状态，连续请求同一个 URL 就能看出缓存行为：
x-cache: HIT
age: 17455
cache-control: public, max-age=604800, s-maxage=43200- 看 x-cache（或 cf-cache-status、x-cache-status）判断本次是否命中；
- 看 age 是否随请求递增——递增说明命中的是同一份副本，归零说明副本被换掉了；
- 第一次请求未命中是正常的（副本还没建立），第二次仍未命中才值得追查；
- 大文件另外带 Range 请求测一次，确认分片缓存是否生效。
在你的网站验证
边缘核验对你自己的 URL 连发多次请求，实测命中状态与 age 是否递增