Service Worker预缓存：一份不容有误的“离线资源契约”
许多开发者存在一个常见误区：认为Service Worker注册成功后，预缓存功能便会自动生效。事实并非如此。预缓存是一份需要开发者亲自、准确、无误地配置的“离线资源契约”。它必须在Service Worker的install生命周期事件中，通过caches.open()与cache.addAll()方法进行显式声明与写入。这份契约遵循一项严格规则：资源列表中任何一个文件加载失败，整个安装流程便会中止——这是最易被忽视、也最常导致Service Worker“失效”的核心约束。
为何 cache.addAll() 易导致 Service Worker 安装失败
根本原因在于cache.addAll()是一个原子性操作。这意味着，只要传入的URL数组中，任意一个资源返回了404、500等错误状态码，或因跨域策略（如未配置CORS的图片）被浏览器拦截，整个Promise就会立即被拒绝。其后果是install事件中断，Service Worker将停滞在waiting阶段，既无法激活，也不能拦截后续的任何网络请求。
如何有效规避这一风险？你需要重点关注以下几个方面：
- 精确校验资源路径：确保
urlsToCache数组内的所有路径均可正常访问。特别注意根路径'/'，它通常指向index.html文件，而非服务器目录列表。 - 避免缓存动态URL：切勿缓存带有版本哈希或时间戳参数的资源（例如
/app.js?v=123）。这类URL在每次构建后都会变化，若Service Worker脚本未同步更新，下次安装时请求旧URL必然触发404错误。 - 借助构建工具自动化：对于CSS、JavaScript、图片等静态资源，建议通过Webpack等构建工具生成稳定路径，或直接使用
workbox-precache等库自动注入资源清单。手动维护静态资源列表，出错概率极高。
self.addEventListener('install', ...) 中必须使用 event.waitUntil()
这里涉及一个关键的执行时机问题。如果在install事件监听器内未使用event.waitUntil()包裹缓存操作，浏览器会判定安装事件“已完成”，随即进入activate阶段。此时，caches.open()可能仍在进行，cache.addAll()实际上并未执行完毕，导致预缓存未能生效。
正确的代码结构应为：event.waitUntil(caches.open(...).then(cache => cache.addAll(...)))。
此外，若需实现分批次缓存（例如优先缓存核心HTML与CSS，再缓存次要图片），直接链式调用多个addAll()并不可行，因其仍受原子性约束——一组失败，整体失败。可行的替代方案是结合cache.addAll()与cache.put()进行组合式操作。开发阶段还有一个实用技巧：在Chrome开发者工具的Application → Service Workers面板中，勾选“Update on reload”选项，可强制每次页面刷新时重新安装Service Worker，极大便利于验证安装流程的正确性。
缓存名称（CACHE_NAME）变更后，旧缓存不会自动清除
当你更新CACHE_NAME并重新注册Service Worker后，新版本会正常安装并激活。然而，旧版本的缓存文件仍会保留在存储空间中，不仅占用用户磁盘容量，在调试时也可能引发混淆。因此，必须在activate事件中显式执行清理操作。
具体实现方式如下：在激活阶段添加类似代码：caches.keys().then(keys => Promise.all(keys.filter(k => k !== CACHE_NAME).map(k => caches.delete(k))))。
还需注意两个细节：首先，activate事件通常仅在无旧版Service Worker控制页面时立即触发。若旧版本仍在运行，新版Service Worker会处于waiting状态，直至所有标签页关闭或主动调用skipWaiting()。其次，在调试过程中，可直接通过Application → Cache Storage面板手动删除旧缓存名称，这比等待自动清理更为直观高效。
归根结底，Service Worker预缓存的本质是一份“离线优先”的资源契约。开发者向浏览器声明了哪些资源必须离线可用，浏览器便严格依据此清单进行校验。路径错误、权限缺失、时机不当，均会导致契约失效——这并非程序缺陷，而是其设计哲学的体现。理解并遵循这份契约的严谨性，是掌握Service Worker预缓存技术的关键第一步。
