HTML怎么做SW预缓存_HTML Service Worker预缓存资源【整理】
来源：互联网 2026-04-19 09:10:02Service Worker预缓存：一个资源都不能错的“离线契约” 许多开发者存在一个常见误解，认为Service Worker注册成功后，预缓存便会自动生效。事实并非如此。预缓存是一份需要你亲自、准确无误地填写的“离线契约”。它必须在install事件中，通过caches.open()和cache
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.jsv=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 DevTools的Application → Service Workers面板中，勾选“Update on reload”选项，可以强制每次刷新页面时都重新安装Service Worker，非常便于验证安装流程是否正确。
缓存名（CACHE_NAME）更改后，旧缓存不会自动删除
当你更新CACHE_NAME并重新注册Service Worker后，新版本的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仍在运行，新的Service Worker会卡在waiting状态，直到所有标签页关闭，或你主动调用skipWaiting()。其次，在调试阶段，你可以直接打开Application → Cache Storage，手动删除旧的缓存名称，这比等待自动清理更为直观。
归根结底，预缓存的本质是一份“离线优先”的契约。你向浏览器声明了哪些资源是必须存在的，浏览器便严格按此清单校验。路径错一个、权限少一个、时机早一秒，它都拒绝履约——这不是程序的缺陷，而是其设计哲学使然。理解并尊重这份契约的严谨性，是掌握Service Worker预缓存的第一步。
侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述
