Service Worker 更新后旧缓存不消失怎么设计版本清理

页面已经部署了新版本，用户却还看到旧 JavaScript，打开 Cache Storage 还能发现一串旧缓存名，这通常不是“浏览器不更新”，而是 Service Worker 的更新与缓存清理分属两个生命周期。稳妥做法是给每次静态资源发布使用新的缓存名，在 install 中准备新资源，在 activate 中删除明确不再使用的旧缓存。

先换缓存名，再在 activate 清理旧版本；不要把新旧资源写进同一个缓存，也不要在 install 阶段贸然删除旧缓存。

为什么改了 sw.js，旧缓存还在

Service Worker 脚本发生变化后，新 worker 会先在后台安装。安装期间，旧 worker 仍可能控制已经打开的页面，所以旧缓存不能立即删除；它仍是旧页面请求所依赖的资源集合。即使新 worker 已经安装，如果没有清理逻辑，Cache Storage 里的旧键也会一直保留。

另一个常见坑是始终调用 caches.open("app-shell")。新旧 worker 共享同一个名字时，资源会互相覆盖，问题变成“某个页面拿到了一半新、一半旧的文件”，比单纯多占一点空间更难排查。

用版本化缓存拆开安装与清理

先把发布版本写入缓存名。版本号可以来自构建号、Git 提交短哈希或人工维护的发布标识，关键是同一次发布的 HTML、CSS 和 JavaScript 使用同一个值。

const CACHE_NAME = "app-shell-v3";
const PRECACHE_URLS = ["/", "/index.html", "/app.css", "/app.js"];

self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => {
      // 新版本先完整写入自己的缓存，不碰旧版本。
      return cache.addAll(PRECACHE_URLS);
    }),
  );
});

event.waitUntil() 让安装生命周期等待资源写入完成；如果关键资源加入失败，安装应失败，而不是留下一个看似成功但不完整的缓存。此时旧 worker 仍有机会继续服务现有页面。

在 activate 中只删除旧版本

新 worker 激活后，再读取所有缓存键，只保留当前版本。删除操作也要交给 event.waitUntil()，这样清理完成前不会进入新的 fetch 生命周期。

self.addEventListener("activate", (event) => {
  event.waitUntil(
    caches.keys().then((keys) => {
      // 只保留本次发布的缓存，避免误删运行时数据缓存。
      const oldKeys = keys.filter(
        (key) => key.startsWith("app-shell-") && key !== CACHE_NAME,
      );
      return Promise.all(oldKeys.map((key) => caches.delete(key)));
    }),
  );
});

这里用前缀限制删除范围，比“删除所有不是当前键的缓存”更安全，因为项目可能还有图片、接口或离线表单等独立缓存。清理函数可以重复执行，下一次 activate 只会再次检查，不应依赖某个旧键一定存在。

让新旧客户端平稳切换

默认情况下，新 worker 不会立刻抢占仍由旧 worker 控制的页面；这能避免同一个页面在运行旧代码时突然拿到新资源。若应用的资源协议兼容，可以在安装后调用 self.skipWaiting()，再在激活时调用 clients.claim()，但这两个动作解决的是接管时机，不是资源版本兼容。

更实际的策略是：静态资源文件名带内容哈希，HTML 保持可回退；新版本激活后通过页面消息提示刷新，或只对明确兼容的补丁使用立即接管。测试时至少覆盖旧页面打开、发布新版本、刷新、关闭旧页面和重新打开五种状态。若旧页面引用的接口字段已删除，就不要为了“马上生效”强行接管。

常见问题与边界

只修改缓存名，不修改 sw.js 会更新吗？

浏览器通常依据 worker 脚本内容检查更新；仅改构建资源而脚本字节不变，不能把它当作可靠的更新触发方式。生产构建应让 worker 生成内容随资源清单变化。

为什么 activate 清理后旧页面还能显示旧内容？

旧页面可能仍由旧 worker 控制，或者它已经拿到了旧响应。清理缓存不等于刷新 DOM；应先确认控制页面的 worker，再决定是否提示刷新。

可以直接删除所有缓存吗？

不建议。只删除自己约定的版本前缀，保留运行时数据、离线草稿或其他模块的缓存，避免一次发布破坏不属于当前 shell 的数据。

排查“更新后旧缓存不消失”时，先看缓存名是否版本化，再看清理是否放在 activate，最后确认旧页面的控制关系。把版本边界和接管时机分开，Service Worker 的更新行为就会从“偶尔拿到旧文件”变成可解释、可回退的发布流程。