Service Worker 实现静态资源永不过期缓存方法

Service Worker 无法真正实现“永不过期”缓存，因为 HTTP 的 Cache-Control: immutable 仅优化浏览器条件请求，既不阻止 SW 主动删除，也无法应对资源 URL 变更带来的缓存失效；真正让静态资源在用户设备上长期、稳定、可控驻留的关键，在于采用版本化 cacheName（如 static-v1.2.0）、install 阶段精准预缓存、fetch 时标准化 URL（剔除干扰参数）以确保 match 成功，以及在 activate 阶段有策略地清理明确废弃的旧缓存——这一切都依赖开发者对缓存生命周期的主动掌控，而非寄望于浏览器自动管理。

Service Worker 无法真正实现“永不过期”缓存，但可以通过 caches.open() + 版本化命名 + 显式不清理，让特定静态资源在用户设备上长期驻留——前提是开发者主动控制生命周期，而非依赖浏览器自动过期。

为什么不能靠 Cache-Control: immutable 实现“永不过期”

Cache-Control 的 immutable 是 HTTP 层的提示，只影响浏览器是否发起条件请求（如 If-None-Match），但它不阻止 Service Worker 主动调用 cache.delete()，也不影响 caches.keys() 列出的 cache 名称。更关键的是：immutable 要求资源 URL 永远不变，而实际项目中一旦 JS/CSS 更新，必须换 URL（否则用户永远拿不到新版）。所以它和 SW 缓存是两套机制，混用反而容易错乱。

常见错误现象：

• 给未哈希的 app.js 加了 Cache-Control: max-age=31536000, immutable，更新后用户仍加载旧版，且无法通过 skipWaiting() 强制刷新
• SW 中用 caches.open('static') 写入资源，但后续升级时没清理旧 cache，导致磁盘占用持续增长，甚至触发浏览器自动回收

用版本化 cacheName 实现语义化“长期驻留”

所谓“永不过期”，本质是让某一批资源在用户设备上尽可能久地存在，直到你明确决定淘汰它。这靠的是 cache 名称的版本控制，而不是时间戳或随机字符串。

实操建议：

• 命名格式统一为 static-v1.2.0 或 assets-202604，其中版本号/日期来自构建产物 manifest 或 CI 环境变量，确保每次构建产出唯一 cacheName
• 在 install 事件中只写入当前版本资源，不要复用旧 cache；例如：caches.open('static-v1.2.0').then(cache => cache.addAll(['/css/main.css', '/js/app.js']))
• 避免使用 'static-cache' 这类无版本名称——下次 install 时若仍用它，addAll() 会覆盖已有条目，但旧资源响应体可能残留，造成 inconsistent state

match() 时忽略查询参数与标准化请求

静态资源 URL 常带构建哈希（如 /js/app.a1b2c3.js），但某些场景下会额外拼接调试参数（?debug=true）或埋点参数（&t=1713633681）。若直接用原始 Request 对象调用 cache.match(request)，因 URL 不完全一致，匹配失败，导致回源。

解决方法是标准化请求再匹配：

• 提取 URL 主干：用 new URL(request.url).origin + new URL(request.url).pathname 去掉 query 和 hash
• 重建 Request 对象：cache.match(new Request(cleanUrl, { method: request.method }))
• 注意：若资源启用 CORS，需同步传入 credentials: request.credentials，否则 match 失败

示例片段：

self.addEventListener('fetch', e => {
  const url = new URL(e.request.url);
  if (url.pathname.startsWith('/js/') || url.pathname.startsWith('/css/')) {
    const cleanUrl = `${url.origin}${url.pathname}`;
    e.respondWith(
      caches.match(new Request(cleanUrl, { method: 'GET', credentials: 'same-origin' }))
        .then(r => r || fetch(e.request))
    );
  }
});

activate 阶段只删明确废弃的 cache

“长期驻留”不等于“永不清理”。旧 cache 必须在 activate 事件中显式删除，否则多个版本并存会浪费存储空间，极端情况下触发浏览器限制（Chrome 对单个 origin 的 cache 总量有隐式上限）。

关键点：

• 先获取当前所有 cache 名称：caches.keys()
• 只删那些不在白名单里的旧版本，例如保留 ['static-v1.2.0', 'static-v1.1.0']，删掉 static-v1.0.0
• 用 event.waitUntil(Promise.all([...])) 确保删除完成后再激活新 SW，防止 fetch 使用中途被删的 cache
• 不要在 install 阶段删旧 cache——此时旧 SW 可能还在处理请求，delete() 会失败或阻塞

最易被忽略的一点：即使你写了 caches.delete('static-v1.0.0')，浏览器也不会立刻释放磁盘空间；它会在所有对该 cache 的引用（包括正在运行的 fetch 请求）结束后才真正清理。所以“删了就立刻变小”是错觉。

终于介绍完啦！小伙伴们，这篇关于《Service Worker 实现静态资源永不过期缓存方法》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！