service worker无法实现真正的版本镜像，仅能通过语义化缓存名、精准url匹配及install/activate分阶段控制模拟；缓存名须含可维护版本标识（如static-prod-v2.3.1），install阶段只写新缓存，activate阶段再清理旧缓存，并确保预缓存url与页面请求url完全一致。
Service Worker 无法实现真正的“版本镜像”，所谓镜像只是通过语义化缓存名 + 精准 URL 匹配 + 分阶段生命周期控制模拟出来的效果。硬套“镜像”概念反而容易在更新时出现资源错乱、白屏或旧 JS 执行新 HTML 的灾难性问题。
缓存名必须带可维护的语义化版本，不能用 v1/v2 这类裸数字
Cache API 没有原子替换能力，caches.open('static') 打开的是一个可变引用。如果新旧版本共用同一个名字，cache.put() 会覆盖条目，但已打开页面仍可能读到被覆盖前的响应体（尤其在 response.body 流未完全消费时）。
正确做法是让缓存名自带环境与构建标识：
-
static-prod-20260428（日期型，适合每日构建） -
static-prod-v2.3.1（语义化版本，需和 package.json 对齐） -
static-prod-<code>git commit hash（最精确，但需构建时注入）
避免用资源哈希（如 app.a1b2c3.js）直接拼进缓存名——它会导致每次构建都生成新缓存名，即使内容没变，白白浪费用户磁盘空间和带宽。
install 阶段只写新缓存，activate 阶段才删旧缓存
这是防止多版本缓存共存引发冲突的关键分界点。若在 install 中就调 caches.delete()，可能误删当前页面正在使用的缓存。
标准流程如下：
-
install：调caches.open('static-prod-v2.3.1')，然后cache.addAll([...])，完成后调self.skipWaiting() -
activate：先self.clients.claim()确保新 SW 接管所有客户端；再遍历caches.keys()，对不匹配当前版本名的缓存调caches.delete(key)
注意：self.clients.claim() 不是可选操作——没有它，旧页面不会触发新 SW 的 fetch 事件，离线访问依然走老逻辑。
URL 必须完全一致才能 match，连 ?v= 和末尾 / 都算不同资源
cache.match() 是精确匹配，不是模糊查找。哪怕页面请求的是 /logo.png?v=2.3.1，而你预缓存的是 /logo.png，结果就是 miss。
常见失配点：
- HTML 中写
<script src="/js/app.js?build=20260428"></script>→ 缓存数组里也得写'/js/app.js?build=20260428' - 开发时用
localhost:3000，生产用https://app.example.com→request.url完全不同，缓存不共享 - 相对路径
'js/app.js'在sw.js位于/sw.js时会被解析为https://app.example.com/js/app.js；但如果sw.js在/js/sw.js，就会变成https://app.example.com/js/js/app.js
结论：所有预缓存 URL 都该用绝对路径，并和构建产物清单（如 Webpack 的 manifest.json）保持一致。
不要依赖 request.destination 判断静态资源类型
request.destination 在跨浏览器或特殊 fetch 调用下并不可靠。比如：
- 用
fetch('/api/config.json', { mode: 'no-cors' })，Chrome 返回destination === 'empty'，Firefox 可能是'json' - 字体文件在 Chrome 是
'font'，Safari 可能是'undefined' - 内联
<link rel="stylesheet">加载 CSS，在某些 UA 下destination是'style'，但用fetch()加载同个 CSS 文件时可能是'undefined'
更稳的方式是正则匹配 URL：
const isStaticAsset = /\.(js|css|png|jpg|jpeg|gif|svg|woff2?|ttf|eot)$/i.test(request.url);
对 HTML 页面仍可用 request.destination === 'document'，这个判断是规范保证可靠的；其余资源一律按路径后缀分流，避免被 UA 差异拖垮策略稳定性。
真正难的不是写对一段 fetch 逻辑，而是让每次构建输出的资源 URL、缓存名、SW 生命周期行为三者严格对齐——差一个查询参数，就等于整个镜像策略失效。
