关键在于资源标识变化和分层缓存策略：构建时为js/css/图片等生成内容哈希文件名（如app.a2f8e1c4.js），使url变更强制浏览器发起新请求；对哈希资源设cache-control: max-age=31536000, immutable，html则设no-cache+etag协商验证。
给静态资源加内容哈希（最核心）
JS、CSS、图片等静态文件，在构建时自动生成带内容哈希的文件名，比如 app.a2f8e1c4.js。只要代码变了，哈希就变，URL 就不同。
- 浏览器把新 URL 当作全新资源，必然发起新请求，完全不走旧缓存
- HTML 文件里引用的 script/link 标签，由构建工具自动更新，无需手动改
- 比时间戳更可靠：不浪费带宽，也不破坏缓存复用价值
HTTP 缓存头要分资源类型设置
前端不能发响应头，但必须和后端或托管平台协同配置：
- 对带哈希的 JS/CSS：设 Cache-Control: max-age=31536000, immutable —— 表示一年内不变，且内容不可变更，浏览器可放心长期强缓存
- 对 HTML 文件：设 Cache-Control: no-cache, must-revalidate + 启用 ETag —— 每次访问都向服务器验证，内容一变就返回新 HTML
- 纯静态部署（如 Vercel/Netlify）可通过
_headers或vercel.json统一配置，不用改代码
用 Service Worker 主动接管更新逻辑（进阶可控）
适合需要离线能力或精细控制缓存的场景：
- 新 SW 安装时，调用 caches.delete('v1') 清掉旧缓存
- fetch 事件中先查 cache，命中则返回；未命中再 fetch 网络并存入新 cache
- 新 SW 需主动调用 self.skipWaiting() 和 clients.claim() 才能立即生效
页面级刷新只作为用户明确意图的兜底手段
不推荐默认使用，但可在“检查更新”按钮点击后触发：
- 先 fetch version.json 对比远程版本号
- 发现有新版本，提示用户并执行 window.location.replace(window.location.href)
- 用 replace 而非 reload，避免后退回到旧状态
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
