直接回答：CDN 缓存设计围绕 cache key 和 TTL 两件事。cache key 决定哪些请求共享一份缓存：URL 路径默认入 key，query 参数、Cookie、Header 是否入 key 要按业务白名单——无差别全入 key 会把命中率打到地板。TTL 由源站 Cache-Control 与 CDN 规则共同决定：静态资源用内容哈希文件名加一年期 immutable，HTML 用短 TTL 加 stale-while-revalidate，API 默认不缓存、个别只读接口显式开启。
展开解析：命中率下降的典型原因：URL 带随机参数（追踪参数 utm、时间戳）导致每个请求都是新 key；Cookie 全量入 key 人人一份缓存；TTL 太短或源站错误地发了 no-store；流量稀疏的冷内容天然命中率低（长尾视频文件），这是内容属性不是故障。穿透与回源风暴的对应手段：回源合并（origin shield/请求折叠，同 key 并发回源只放一路）；失效用带版本号的 URL 优于主动 purge（purge 全球生效有延迟且可能打爆源站）；大文件预热（主动 push 到边缘）。观测上盯 edge hit ratio、回源带宽、P95 首字节时间三个指标；记住 CDN 缓存是性能优化不是正确性机制，任何"必须立刻生效"的内容都不该依赖 TTL 到期。
追问方向：Cache-Control 的 s-maxage 与 max-age 区别？为什么 HTML 不宜长缓存？灰度发布如何利用 cache key？
（约 460 字）