CDN 缓存命中率优化实战：四个动作把命中率从 60% 拉到 90%

接入 CDN 之后，最容易被忽略的一个指标是缓存命中率。命中率低意味着大量请求穿回源站：源站带宽、数据库连接、响应时延同时被放大，CDN 的钱花了却没起效果。把命中率从 60% 提到 90%，通常不需要大改架构，四个动作就能落地。

一、缓存规则按资源类型分层。很多站点给全站配了统一的 30 分钟缓存，结果 HTML 更新不及时、图片却反复回源。正确做法是分层：HTML 入口文件缓存时间短（0 到 5 分钟）保证能快速发布；带版本号的 JS、CSS 缓存时间长（30 天以上）；图片、字体这类几乎不变的资源缓存 180 天。同时要注意 URL 参数处理：营销链接常带 utm_source 这类无关参数，应在控制台开启「忽略 URL 参数」避免同一份资源被拆成无数副本，但对 ?v=1.2 这种真正区分版本的参数要保留。

二、回源链路本身要调优。回源 HOST 必须与源站域名一致，否则源站返回默认站点或直接 403；大文件场景开启 Range 回源，让 CDN 分片拉取而不是整文件重取；合理设置回源超时与重试次数，避免源站抖动时回源请求被放大成雪崩。 HTTPS 场景下可开启回源协议跟随，减少一次协议转换开销。

三、版本发布后主动预热。静态资源更新后，第一批用户访问必然回源，热点页面尤其明显。发布流程里加上预热步骤：把首页、活动页、新版本 JS/CSS 的 URL 提交预热，让边缘节点提前有副本。这里要分清刷新和预热的区别：刷新是让节点丢弃旧文件，用于纠错；预热是让节点主动拉取新文件，用于加速。先刷新再预热，才是完整的发布动作。

四、资源治理与监控联动。根治命中率问题的手段是资源指纹化：文件名带内容 hash，内容变化才换 URL，因此可以放心给它们设置超长缓存，而 index.html 保持短缓存负责调度。监控上不要只看命中率，要把命中率、回源带宽、5xx 与 404 状态码分布放在一起看：命中率突然下跌，先查是不是新版本没预热、URL 参数变了、还是某个接口被误配成了可缓存却带了个性化响应。

总结：缓存规则分层是基础，回源链路调优是保障，发布预热是临门一脚，资源指纹加监控联动让命中率长期稳定。四步做完，命中率与源站成本通常都会有肉眼可见的变化。