Cache.addAll() 是 Service Worker 预缓存静态资源最直接可靠的方式，需在 install 事件中用 waitUntil 包裹，仅支持绝对或相对路径，要求资源真实存在且同源或配置 CORS，缓存名应版本化并在 activate 阶段清理旧缓存。
Cache.addAll() 是 Service Worker 中实现静态资源预缓存最直接、最可靠的方式，适用于构建明确可控的缓存白名单——即你完全清楚哪些资源必须在安装阶段就进入缓存，且不希望它们被动态请求干扰。
只接受绝对路径或相对路径（相对于当前脚本）
Cache.addAll() 接收一个 URL 字符串数组，所有路径必须能被 fetch 正确解析。常见错误是传入以 / 开头的绝对路径却未带上协议和域名（如 "/css/app.css"），这在 SW 脚本中是合法的，但前提是这些路径在页面上下文中实际可访问；更稳妥的做法是统一使用相对路径（如 "css/app.css"）或完整 URL（如 "https://example.com/css/app.css"）。
- 推荐用相对路径：简洁、可移植，尤其适合同源部署
- 避免混合协议/域名：跨域资源需确保 CORS 配置允许，否则 addAll 会静默失败
- 路径必须真实存在：如果某个文件 404，整个 addAll 操作会 reject，导致 install 事件失败，SW 安装中断
必须在 install 事件中调用，并配合 waitUntil
预缓存逻辑必须放在 self.addEventListener('install', ...) 内，并用 event.waitUntil() 包裹 Cache.addAll() 的 Promise，否则浏览器可能在缓存完成前就结束安装流程。
- 不加 waitUntil → 缓存可能未完成，SW 就进入 waiting 状态
- addAll 失败时，install 事件自动失败，旧 SW 继续运行，不会影响用户当前体验
- 可在 waitUntil 中链式处理：比如缓存成功后跳过等待（
self.skipWaiting()），但需谨慎评估更新策略
缓存名建议按版本隔离，避免冲突
不要硬编码缓存名如 "static-v1"，而应结合构建版本或时间戳生成唯一缓存名（例如 `static-${VERSION}`），并在 activate 阶段清理旧缓存。
- 新版 SW 安装时创建新缓存，不影响旧缓存中的资源
- 在 activate 事件中调用
caches.keys().then(keys => ...)删除非当前版本的缓存 - 这样既保证预缓存原子性，又避免残留垃圾缓存占用空间
不是万能的——它不处理动态资源或运行时策略
Cache.addAll() 只解决“安装时确定要缓存什么”的问题。它不关心网络状态、不支持条件缓存、也不参与 fetch 事件的运行时决策。
- HTML 页面通常不适用 addAll：因为 HTML 常含动态内容或服务端渲染，应走 runtime caching + network-first 或 stale-while-revalidate
- 需要根据请求头、用户角色、A/B 实验等条件缓存？得靠 fetch 事件中手写逻辑
- 想压缩缓存体积或按需加载？需配合 importScripts、代码分割、或缓存分组策略
