html Service Worker缓存

2026-04-24 11:00:10 1679阅读 0评论

用 Service Worker 缓存打造更稳的离线体验

在移动端，用户从加载页面到数据可用，常经历几秒钟的空窗；在弱网或设备刚上线时，这空窗更像“断点”。用 Service Worker 做本地缓存，能减少对网络的依赖，让内容在“可用但不完美”的状态提前呈现，既提升感知速度，也提升容错能力。

从“等资源”到“可用即缓存”

你不必等所有资源下载完成就让用户看到内容。通过在 install 阶段预先缓存关键资源，并在 fetch 时优先返回缓存，页面能更早可用。像文章、图片、样式与脚本，甚至部分 API 响应，都能被纳入缓存策略，具体选择看你的场景与优先级。

核心做法：在 install 时只缓存需要的资源，避免体积过大；在 fetch 时用缓存优先，网络仅作备选（Cache-First）。

缓存策略与缓存寿命：精细控场

“缓存多久？”“缓存什么？”这两件事决定策略的成败。

缓存范围：按资源类型划分缓存桶，如 html、images、fonts、css、scripts、api-responses，分别设置独立的缓存策略与寿命。
缓存寿命：对 api 响应可以设定较短的 TTL（如 5–15 分钟），图片与静态内容可设更长的（如 24 小时），并在页面隐藏或用户主动刷新时触发更新。
更新机制：在 Service Worker 生命周期内定期检查更新，或在特定事件（如 push、用户点击）触发更新，保证缓存与服务器数据的同步。

实战：从配置到生效的最小可运行例子

// sw.js
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open('my-cache-v1').then(cache => {
      return cache.addAll([
        '/', '/style.css', '/main.js', '/images/logo.png',
        '/api/data?version=1', '/api/data?version=2'
      ]);
    })
  );
});

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.open('my-cache-v1').then(cache => {
      return cache.match(event.request).then(response => {
        if (response) {
          return response;
        }
        return caches.open('my-cache-v1').then(cache => {
          return fetch(event.request).then(fetchResponse => {
            if (fetchResponse && fetchResponse.ok) {
              return cache.put(event.request, fetchResponse.clone());
            }
            return response;
          });
        });
      });
    })
  );
});

这段代码实现了“先用缓存、再用网络”的逻辑，并在首次请求后把匹配资源写入缓存，为后续请求提供更顺畅的体验。