核心是让浏览器“认得清、存得住、用得对”：通过内容哈希+强缓存头（cache-control: public, max-age=31536000）确保js长期有效；分离稳定依赖为独立vendors哈希包提升复用率；动态资源用etag实现精准验证；service worker预缓存+cache-first策略兜底增强命中率。
核心在于让浏览器“认得清、存得住、用得对”——静态资源一旦被正确缓存，二次及后续访问就能跳过网络请求，直接从本地加载，命中率自然飙升。
用内容哈希+强缓存头锁定长期有效资源
JavaScript 文件内容不变时，应确保浏览器复用同一份缓存；内容变更后，则必须让旧缓存失效。这靠两步协同实现：
- 构建时为 JS 文件名注入内容哈希（如
app.a1b2c3.js），保证文件名随代码变化而变化 - 服务器返回
Cache-Control: public, max-age=31536000（即 1 年），告诉浏览器：只要这个文件名没变，就永远信任本地副本 - 避免使用
Expires或仅依赖max-age=0等弱策略，否则无法触发真正意义上的强缓存
分离稳定依赖，提升公共 chunk 复用率
第三方库（如 React、Vue、Lodash）更新频率低、体积大，单独打包并赋予独立哈希，能显著拉高整体缓存命中率：
- 配置 Webpack/Vite 的
splitChunks，将node_modules中的模块抽成vendors.[hash].js - 给这类文件同样配
Cache-Control: public, max-age=31536000 - 用户升级 App 时，业务代码哈希变了，但若 React 版本未变，
vendors文件仍可命中缓存
配合 ETag 实现动态路径下的精准验证
对无法哈希化或需按环境/用户动态生成的 JS（如微前端子应用入口、AB 测试脚本），不能依赖强缓存，但也不能放弃缓存收益：
- 服务器为这类资源生成唯一
ETag（如基于内容 MD5 或版本标识） - 浏览器后续请求自动带上
If-None-Match，服务端比对后返回304 Not Modified - 这种方式虽有一次轻量请求，但不传输主体，仍比全量下载快得多，且保障内容新鲜度
用 Service Worker 补足边缘场景覆盖
HTTP 缓存由浏览器自动管理，但控制粒度粗；Service Worker 可主动干预，兜底提升命中确定性：
- 在
install阶段预缓存关键 JS（如主包、路由骨架） - 在
fetch事件中采用Cache-first策略：优先匹配缓存，仅缓存未命中时才走网络 - 对带查询参数的 JS 请求（如
bundle.js?ts=123），可在 SW 中标准化 URL 再匹配，避免参数扰动导致缓存浪费
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
