在使用 HTML 的 Service Worker 时，activate 事件是清理旧版本缓存数据的关键时机。以下是通过 activate 事件清理旧缓存的详细步骤和代码示例：✅ 1. 了解 activate 事件Service Worker 的生命周期包括以下几个阶段：install：首次安装或更新时触发。activate：当 Service Worker 被激活时触发（通常在安装完成后）。fe

在 Service Worker 的生命周期中，activate 事件是唯一安全、可靠的时机来清理旧版本缓存，避免离线资源混搭（如 v2 的 JS 加载 v1 的 HTML）或缓存残留问题；必须使用 event.waitUntil() 包裹完整的异步清理链（包括 caches.keys() 和所有 caches.delete()），否则浏览器可能提前终止 Worker 导致清理中断；推荐用精确白名单（与 install 阶段实际创建的缓存名严格一致）配合 Promise.all() 并行删除，并为每个 delete 添加 .catch(() => {}) 防止单点失败阻断整体清理——这不仅是最佳实践，更是保障 PWA 稳定更新与离线体验的强制性机制。

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 的执行时机

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~