Cache API 版本化缓存通过命名隔离（如'static-v2.1'）、install阶段预填新缓存、activate阶段清理旧缓存三步实现平滑切换；HTML网络优先，静态资源用哈希命名确保内容匹配。
Cache API 实现版本化缓存管理，核心在于**用命名隔离 + 生命周期控制 + 自动清理**三步联动，避免新旧资源混用、缓存击穿或离线加载错版文件。这不是靠“手动清缓存”，而是通过 Service Worker 的 install/activate 事件机制，让浏览器自动完成平滑切换。
缓存名带版本号，物理隔离不同发布
每个缓存空间用唯一名称标识，例如 'static-v1.2'、'assets-202610' 或 'app-shell-v3'。不能复用固定名（如 'cache'），否则新旧资源会写入同一空间，match() 时无法区分。
- install 阶段调用
caches.open('static-v2.1')创建新缓存，再用addAll()或put()预填新版 HTML/CSS/JS - fetch 阶段只匹配当前版本缓存名，比如始终用
caches.match(request, { cacheName: 'static-v2.1' }) - 版本号建议与构建产物哈希或发布时间强绑定，避免人为误写
activate 阶段清理旧缓存，释放空间防堆积
仅创建新缓存不够——旧缓存若不删，会持续占用存储，且可能被误读（尤其当 fetch 逻辑未严格指定 cacheName 时）。
- 在 activate 事件中遍历
caches.keys()，比对名称是否匹配当前期望版本 - 对不匹配的缓存调用
caches.delete(cacheName)，例如删掉 'static-v1.9' 和 'static-v2.0' - 务必用
event.waitUntil()包裹清理逻辑，确保激活完成前清理完毕
HTML 用网络优先，静态资源用缓存优先 + 哈希防更新失效
版本名解决的是“空间隔离”，但还要防止“内容错配”：比如 index.html 已升级，却仍从旧缓存中读取了未更新的 main.a1b2c3.js。
- HTML 文件推荐 Network-First 策略：先 fetch，成功则返回并可选缓存副本；失败才 fallback 到缓存。保证结构最新
- CSS/JS 资源必须使用内容哈希命名（如
main.f3e8d2a7.js），这样即使缓存未及时清理，新 HTML 引用的也是全新 URL，天然绕过旧缓存 - 若无法改文件名，可在请求 URL 后加版本查询参数（
app.js?v=2.1），并配置match({ ignoreSearch: false })确保参数参与匹配
避免跨版本污染的细节提醒
有些操作看似无关，实则破坏版本一致性：
- 不要在 fetch 中无条件使用
caches.match(request)——它默认搜索所有缓存，应显式传入{ cacheName: CURRENT_CACHE_NAME } - 动态接口（如
/api/user?timestamp=...）不应进版本缓存，需单独跳过或走独立策略 - Request 对象不可复用：若需同时 match 和 fetch，必须先
request.clone()，否则第二次调用会失败 - 跨域资源（字体、图片）若未配 CORS，即使缓存成功，页面加载时也会被浏览器拒绝使用
