Service Worker activate事件清理缓存方法

Service Worker 的 activate 事件是清理旧缓存的唯一安全时机，必须用 event.waitUntil() 严格包裹包括 caches.keys() 和所有 caches.delete() 调用在内的完整异步清理链，否则浏览器可能提前终止 Worker，导致版本混杂（如 v2 JS 加载 v1 HTML）、离线失效或 DevTools 中残留不可见的旧缓存；白名单需与 install 阶段实际创建的缓存名完全一致，避免模糊匹配或动态命名不同步，并推荐用 Promise.all() 并行删除+单个 .catch() 容错，而非串行或在 install/fetch 中误删——这些细节看似微小，却直接决定缓存升级是否原子、可靠、零感知。

activate 事件里删缓存为什么必须用 event.waitUntil()

不加 event.waitUntil()，浏览器可能在清理完成前就终止 Service Worker，导致部分旧缓存残留——你改了版本号、发了新 SW，用户却还在用 v1 的 CSS 或 HTML。这个包装不是可选的，是强制的生命周期保障机制。

常见错误现象：缓存名看着删了，但 DevTools 的 Application → Cache Storage 里还能看到旧缓存；或者页面离线后加载出混搭内容（v2 的 JS + v1 的 HTML）。

• event.waitUntil() 必须包裹整个异步清理链，包括 caches.keys() 和所有 caches.delete()
• 不能只包 caches.keys()，否则 Promise.all(...) 可能被丢弃
• 如果用了 self.clients.claim()，也建议一并包进去，确保接管和清理原子性

怎么写 cacheWhitelist 才不会漏掉当前缓存

白名单不是靠猜，得和 install 阶段实际打开的缓存名严格一致。比如你在 install 里写了 caches.open('v3-static') 和 caches.open('v3-dynamic')，那 CURRENT_CACHES 就必须包含这两个字符串，一个字母都不能差——大小写、连字符、顺序都不影响逻辑，但必须完全匹配。

容易踩的坑：

• 用正则或模糊匹配（如 /^v\d+-/）看似灵活，但若未来引入 v3-legacy 这类非标准命名，就会误删
• 把缓存名写成变量但没导出，或在不同模块里重复定义，导致 activate 用的白名单和 install 用的不一致
• 动态生成缓存名（如带时间戳），却没在 activate 里同步更新白名单逻辑

caches.delete() 并行删还是串行删

用 Promise.all() 并行删是标准做法，性能好、代码简洁。但要注意：只要其中一个 caches.delete(name) 拒绝（比如缓存名不存在或权限异常），整个 Promise.all() 就会失败，导致清理中断。

更稳妥的做法是捕获单个删除失败，不让它影响全局：

cacheNames.map(cacheName => {
  if (!cacheWhitelist.includes(cacheName)) {
    return caches.delete(cacheName).catch(() => {}); // 忽略单个失败
  }
})

适用场景：

• 开发环境：加 console.log('deleted:', cacheName) 方便验证是否删对了
• 生产环境：去掉日志，但保留 .catch(() => {}) 防止因脏数据（如手动创建的测试缓存）导致激活失败
• 不推荐串行（reduce(Promise.resolve(), ...)），慢且无必要

为什么不能在 install 或 fetch 里删旧缓存

install 阶段删，旧 SW 还在运行，页面正从旧缓存读资源，你一删，立刻触发 TypeError: Request failed；fetch 阶段删，请求正在途中，缓存被删一半，后续 match 失败，用户看到白屏或断图。

activate 是唯一安全窗口：新 SW 已安装完成、旧 SW 已停止控制客户端（尤其配合 self.clients.claim() 后），此时删，不影响任何正在进行的请求。

额外提醒：

• 别在 fetch 事件里调 caches.delete() ——哪怕只是想“顺手清理”，这是最常被忽略的竞态源头
• 如果用了自定义缓存策略（比如按 URL 哈希分片），白名单就得覆盖所有可能生成的缓存名，不能只列主干名
• Chrome DevTools 里点「Skip waiting」能跳过等待用户关闭所有标签页的过程，但不会绕过 activate 的执行时机

今天关于《Service Worker activate事件清理缓存方法》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！