Service Worker Cache API 更新资源如何避免旧缓存覆盖

Service Worker 更新后仍然读到旧的 JavaScript、CSS 或 HTML，通常不是浏览器“没有刷新”，而是旧 worker、旧缓存和全局匹配范围同时存在。稳定的处理方式是：给 Cache API 使用带版本号的缓存名，在 install 中创建新缓存，在 activate 中删除旧版本，并让 fetch 只匹配当前缓存。

为什么更新后旧缓存还会被命中

Service Worker 更新时，新脚本会先安装，已有页面仍可能由旧 worker 控制。此时如果新版本继续写入同一个缓存名，旧 worker 和新 worker 可能互相覆盖；如果直接调用 caches.match(request)，它还可能在多个 Cache 对象中找到较早创建的响应。

先把读取范围收窄到当前版本缓存，问题会清楚很多：

const CURRENT_CACHE = "app-static-v2";

self.addEventListener("fetch", (event) => {
  event.respondWith((async () => {
    // 只在当前版本缓存中查找，避免误读旧版本资源。
    const cache = await caches.open(CURRENT_CACHE);
    const cached = await cache.match(event.request);
    return cached || fetch(event.request);
  })());
});

这段代码解决的是“读错缓存”，但还没有解决“旧缓存越来越多”。缓存版本切换和清理必须配合使用。

用 install 和 activate 分开处理版本切换

把安装资源和清理资源分成两个生命周期阶段，可以让旧页面在过渡期间继续工作。新 worker 安装时创建 app-static-v2，旧 worker 仍可以读取 app-static-v1；等新 worker 进入激活阶段，再删除已经不需要的旧版本。

const CACHE_VERSION = "v2";
const CACHE_PREFIX = "app-static-";
const STATIC_CACHE = `${CACHE_PREFIX}${CACHE_VERSION}`;
const APP_SHELL = ["/", "/index.html", "/styles.css", "/app.js"];

self.addEventListener("install", (event) => {
  event.waitUntil((async () => {
    // 新版本写入独立缓存，避免覆盖仍在使用的旧缓存。
    const cache = await caches.open(STATIC_CACHE);
    await cache.addAll(APP_SHELL);
  })());
});

self.addEventListener("activate", (event) => {
  event.waitUntil((async () => {
    // 只清理本应用前缀下的旧缓存，避免误删同源的其他应用数据。
    const names = await caches.keys();
    await Promise.all(
      names
        .filter((name) => name.startsWith(CACHE_PREFIX) && name !== STATIC_CACHE)
        .map((name) => caches.delete(name)),
    );

    // 清理完成后，才让当前作用域的页面使用新 worker。
    await clients.claim();
  })());
});

event.waitUntil() 很关键：它让浏览器等待缓存填充或旧缓存删除完成，再处理后续功能事件。删除条件要带应用前缀；因为 Cache Storage 按源共享，简单地删除所有不等于当前名称的缓存，可能误伤同一源下的其他应用。

fetch 读取范围和页面接管要分别做决定

版本缓存解决了资源命名问题，但不代表页面会立即切换到新 worker。默认情况下，新 worker 会等待旧页面释放控制权；这是较稳妥的发布方式。只有当新旧页面和资源协议兼容时，才考虑在安装完成后调用 self.skipWaiting()，再在激活时调用 clients.claim()。

生产环境可以按下面的清单检查：

三个容易忽略的边界

第一，缓存版本变化不会自动让旧资源消失，删除逻辑必须显式写在 activate。第二，缓存名只表达版本，不负责判断资源内容是否安全，cache.addAll() 失败时仍要让安装事件失败并保留旧 worker。第三，HTML、JS 和 API 响应的更新策略不一定相同，应用壳适合版本化缓存，用户数据则要谨慎使用缓存优先。

常见问题

只修改缓存名，为什么页面还是旧的？

新 worker 可能还处于 waiting，当前页面仍由旧 worker 控制。先确认激活状态，再决定是否刷新页面或采用接管策略。

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

不建议。Cache Storage 与同源应用共享，应该用应用专属前缀筛选，只删除自己管理且不在当前保留名单中的缓存。

什么时候应该调用 skipWaiting？

当新旧页面能同时处理同一套资源和消息协议时再用。若新脚本依赖新 HTML 或新数据格式，默认等待通常更安全。