HTML中Cache API的cache.addAll批量缓存资源列表的用法-html教程-PHP中文网

cache.addall() 是原子操作，任一资源失败（如404、cors问题、非2xx状态等）则全部不缓存，导致service worker卡在installing状态；必须用event.waituntil()包裹整个promise链，使用绝对路径或完整url，并配套更新缓存名与清理旧缓存。

html中cache api的cache.addall批量缓存资源列表的用法

cache.addAll() 为什么一失败就全不缓存

因为它是原子操作：数组里任意一个 URL 返回 404、跨域但没配 CORS、响应状态不是 2xx（比如 302、500）、甚至请求方法不是 GET，整个 cache.addAll() 就直接 reject，已处理的资源一个都不会进缓存，install 事件中断，Service Worker 卡在 installing 状态，后续 fetch 事件压根不会触发。

常见踩坑点：

忘了检查服务器返回的 Cache-Control: no-store —— 比如 SSR 渲染的 / 页面带这个头，cache.addAll(['/']) 会静默失败
路径写成 './app.js' 或 'js/app.js'，但在 SW 脚本中相对路径解析基准是 SW 文件本身，不是 HTML 页面，容易 404
混用协议或域名，比如页面是 https://example.com，却在列表里写 'http://cdn.example.com/logo.png'，没开 CORS 就失败

路径怎么写才保险

必须用浏览器能正确 fetch 的 URL 形式。SW 中不支持 document.baseURI 那套逻辑，只认绝对路径（'/index.html'）或完整 URL（'https://example.com/app.js'），相对路径（'app.js'）只有在 SW 和目标资源同目录时才可靠。

推荐做法：

静态资源统一走根相对路径：'/styles/main.css'、'/scripts/app.js'，前提是你的服务支持这些路径可访问
HTML 文件必须显式列出：'/' 或 '/index.html'，它内部引用的 JS/CSS 不会自动递归抓取
关键图片、字体等同步依赖也得列进去，否则离线时 HTML 加载了，子请求 404
避免带查询参数的路径（如 '/app.js?v=1.2.3'），除非你确定每次构建都更新它；否则建议用构建时注入版本号的缓存名来隔离

event.waitUntil() 不包就等于没写

caches.open() 和 cache.addAll() 都返回 Promise，如果不被 event.waitUntil() 包裹，浏览器会认为 install 事件立刻完成，异步缓存操作可能被中断或丢弃，结果就是缓存看起来“没生效”。

正确写法只有一种结构：

html-deploy

使用 htmlcode.fun 将 HTML 内容或文件部署到网页，适用于用户要求“部署到网页”“托管此 HTML”“生成此前端...的实时链接”等场景。

下载

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open('static-v2').then(cache =>
      cache.addAll([
        '/',
        '/index.html',
        '/styles/main.css',
        '/scripts/app.js'
      ])
    )
  );
});

注意点：

不能把 event.waitUntil() 放在 caches.open() 外层就完事，必须包裹整个链式 Promise
不要在 addAll() 后加 .catch() 吞掉错误 —— 它失败本就应该让 install 失败，旧 SW 继续运行更安全
想跳过 waiting 阶段（比如立即激活新 SW），可在 waitUntil 链末尾加 self.skipWaiting()，但要确保 runtime caching 逻辑已就位，否则可能引发资源不一致

缓存名和旧缓存清理必须配套做

缓存名硬编码成 'static-v1' 是自找麻烦。每次更新资源，应该生成唯一缓存名（比如 `static-${VERSION}`），并在 activate 阶段清理非当前版本的缓存。

否则会出现：

旧缓存残留，占用用户设备空间
不同版本缓存名冲突，导致 caches.open() 拿到意料外的缓存实例
activate 阶段没清理，用户可能长期用着过期的 CSS/JS

清理逻辑示例：

self.addEventListener('activate', event => {
  const CURRENT_CACHE = 'static-v2';
  event.waitUntil(
    caches.keys().then(keys =>
      Promise.all(
        keys
          .filter(key => key !== CURRENT_CACHE)
          .map(key => caches.delete(key))
      )
    )
  );
});

真正容易被忽略的是：这个清理动作必须和 install 阶段的缓存名严格对应，且不能漏掉任何历史版本 —— 构建流程里最好自动生成并注入 CURRENT_CACHE 常量，而不是靠人肉维护。