关键在于分层定策、按类设控、精准失效：HTML禁强缓存，哈希资源永久缓存，固定路径资源短期+校验，CDN资源用s-maxage；Nginx需精确匹配配置；需监控命中率并干预。
构建百万级静态资源的高缓存命中率文件缓存矩阵，关键不在堆容量，而在“分层定策、按类设控、精准失效”。核心是把不同稳定性和更新频率的资源，分配到匹配其语义生命周期的缓存通道中，避免一刀切导致命中率被拖累。
按资源语义划分缓存层级
静态资源不是铁板一块，必须拆解为四类典型角色，每类对应独立的缓存策略与 Cache-Control 组合：
-
入口 HTML（如 index.html）：必须禁强缓存，设为
Cache-Control: no-cache。它不存内容，只起调度作用；一旦被浏览器强缓存，后续带 hash 的 JS/CSS 更新就无法生效。 -
带内容哈希的资源（如 main.a7b8c9.js、app.f3d2e1.css）：走永久强缓存，用
public, max-age=31536000, immutable。文件名含哈希即代表内容唯一，只要 URL 不变，内容永不变，可放心缓存一年且无需校验。 -
固定路径但可能人工更新的资源（如 logo.png、favicon.ico）：设短期强缓存 + 强制校验，如
public, max-age=86400, must-revalidate。一天后过期，但浏览器会发条件请求（If-None-Match），服务端只需返回 304 即可续命，兼顾更新灵活性与命中率。 -
公共库/CDN 分发资源（如 vue.global.prod.js）：启用 CDN 中转层专属控制，用
public, s-maxage=2592000（30 天）。s-maxage 专供代理节点（如 CDN）使用，不影响浏览器本地缓存逻辑，能大幅降低源站回源压力。
服务端配置需对齐策略边界
Nginx 是落地该矩阵的主力，配置要严格匹配上述分类，不能靠 location 正则一锅煮：
- 对带 hash 的资源，用精确正则匹配（如
location ~* \.[a-f0-9]{6,}\.(js|css|png|jpg)$），直接注入add_header Cache-Control "public, max-age=31536000, immutable"； - 对固定路径图标类，单独写 location 块（如
location = /favicon.ico或location ^~ /static/logo/），设置max-age=86400并开启expires与etag； - 入口 HTML 必须排除在所有强缓存规则之外，建议显式拦截：
location = /index.html { add_header Cache-Control "no-cache"; }； - 若使用 Nginx proxy_cache 缓存上游（如 Node 静态服务），需定义独立 keys_zone（如
keys_zone=html_cache:5m），并仅对 HTML 启用，避免污染 JS/CSS 缓存空间。
命中率可观测、可干预
高命中率不是配完就稳，需要闭环监控与主动干预：
- 在 CDN 和 Nginx access log 中打标资源类型（例如用 map 指令将 URI 映射为 $cache_type），再通过日志分析工具统计各类型命中率；
- 对带 hash 资源，命中率应长期维持在 99.5%+；若持续低于 98%，说明存在 URL 构造错误（如未替换 hash）、CDN 缓存穿透或客户端强制刷新行为异常；
- 对固定路径资源，若 24 小时内 304 响应占比低于 60%，说明内容更新频次远低于预期，可适度延长 max-age；若高于 95%，说明频繁变更，需推动改为 hash 版本化发布；
- 上线新版本时，配合缓存预热脚本，主动请求 Top 1000 资源，将它们提前载入 CDN 边缘节点，规避冷启动低命中问题。
避免常见策略污染点
很多团队命中率上不去，往往栽在几个隐蔽但高频的错误上：
- HTML 中引用的 JS/CSS URL 缺少 hash，或构建工具未正确重写路径，导致浏览器始终请求旧 URL，新文件永远进不了缓存；
- CDN 配置了全局默认 TTL（如统一设 1 小时），覆盖了本该永久缓存的 hash 资源，造成大量非必要回源；
- 误对所有静态资源开启 ETag + Last-Modified，而源站生成成本高（如每次 stat 文件），反而拖慢协商缓存效率，对 hash 资源完全没必要；
- 未关闭 Nginx 的
gzip_vary on对于已压缩资源（如 .js.gz），会导致同一资源因 Accept-Encoding 差异产生多个缓存副本，稀释命中率。
