分析 Service Worker 中的 Cache Storage API 如何实现离线缓存和请求拦截，以及它的更新策略。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位观众老爷们，晚上好！今儿咱们不聊八卦，聊聊Service Worker里头的Cache Storage API，看看这玩意儿怎么玩转离线缓存，拦截请求，以及它那磨人的更新策略。准备好了吗？咱们开始！

Service Worker：前端界的“管家婆”

首先，咱们得弄明白Service Worker是个啥。简单来说，它就像一个默默守护在你浏览器背后的“管家婆”，专门负责处理一些幕后工作，比如推送消息，后台同步，以及今天的主角——离线缓存。

Cache Storage API：你的专属小仓库

Cache Storage API是Service Worker用来管理缓存的得力助手。你可以把它想象成你的专属小仓库，专门存放你网站的各种资源，比如HTML，CSS，JS，图片等等。这个仓库可不是随便谁都能进的，只有Service Worker才能自由出入。

Cache Storage API 的基本操作

Cache Storage API提供了几个核心方法，咱们来逐个击破：

caches.open(cacheName)：打开你的仓库大门

这个方法用来打开一个指定名称的缓存仓库。如果这个仓库不存在，它会自动创建一个。
```
const cacheName = 'my-awesome-cache-v1';

caches.open(cacheName)
  .then(cache => {
    console.log('Cache opened:', cacheName);
  });
```
这段代码的意思是，打开一个名为my-awesome-cache-v1的缓存仓库。如果仓库已经存在，就直接打开；如果不存在，就创建一个新的。
cache.add(url)：往仓库里搬东西

这个方法用来把一个URL对应的资源添加到缓存仓库里。它会发起一个网络请求，获取资源，然后把资源存到仓库里。
```
const urlToCache = '/index.html';

caches.open(cacheName)
  .then(cache => {
    return cache.add(urlToCache);
  })
  .then(() => {
    console.log('Added to cache:', urlToCache);
  });
```
这段代码的意思是，把/index.html这个资源添加到my-awesome-cache-v1缓存仓库里。

cache.addAll(urlArray)：批量搬运工

这个方法一次性把多个URL对应的资源添加到缓存仓库里。

const urlsToCache = [
  '/',
  '/index.html',
  '/css/style.css',
  '/js/app.js',
  '/images/logo.png'
];

caches.open(cacheName)
  .then(cache => {
    return cache.addAll(urlsToCache);
  })
  .then(() => {
    console.log('All resources added to cache!');
  });

这段代码的意思是，把urlsToCache数组里的所有资源都添加到my-awesome-cache-v1缓存仓库里。

cache.match(request)：在仓库里找东西

这个方法用来在缓存仓库里查找与指定请求匹配的资源。如果找到了，就返回缓存的Response对象；如果没找到，就返回undefined。
```
caches.open(cacheName)
  .then(cache => {
    return cache.match('/index.html');
  })
  .then(response => {
    if (response) {
      console.log('Found in cache:', response);
      // 返回缓存的资源
      return response;
    } else {
      console.log('Not found in cache');
      // 从网络获取资源
      return fetch('/index.html');
    }
  });
```
这段代码的意思是，在my-awesome-cache-v1缓存仓库里查找/index.html对应的资源。如果找到了，就返回缓存的Response对象；如果没找到，就从网络获取资源。
cache.put(request, response)：把东西放回仓库

这个方法用来把一个Request对象和对应的Response对象存到缓存仓库里。
```
fetch('/api/data')
  .then(response => {
    // 克隆 Response 对象，因为 Response 对象只能读取一次
    const responseToCache = response.clone();

    caches.open(cacheName)
      .then(cache => {
        cache.put('/api/data', responseToCache);
      });

    return response;
  });
```
这段代码的意思是，从/api/data获取数据，然后把请求和响应存到my-awesome-cache-v1缓存仓库里。注意这里要clone一下response，因为response只能读取一次。

caches.delete(cacheName)：拆仓库

这个方法用来删除一个指定名称的缓存仓库。

caches.delete(cacheName)
  .then(success => {
    if (success) {
      console.log('Cache deleted:', cacheName);
    } else {
      console.log('Cache not found:', cacheName);
    }
  });

这段代码的意思是，删除名为my-awesome-cache-v1的缓存仓库。

Service Worker 如何实现离线缓存和请求拦截

Service Worker的核心功能就是拦截网络请求，然后决定是从缓存里取资源，还是从网络获取资源。这个过程主要发生在Service Worker的fetch事件监听器里。

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // 缓存命中
        if (response) {
          return response;
        }

        // 缓存未命中，从网络获取
        return fetch(event.request).then(
          response => {
            // 检查是否收到了有效的响应
            if (!response || response.status !== 200 || response.type !== 'basic') {
              return response;
            }

            // 克隆 Response 对象，因为 Response 对象只能读取一次
            const responseToCache = response.clone();

            caches.open(cacheName)
              .then(cache => {
                cache.put(event.request, responseToCache);
              });

            return response;
          }
        );
      })
  );
});

这段代码的流程是这样的：

当浏览器发起一个网络请求时，Service Worker会拦截这个请求。
Service Worker尝试在缓存仓库里查找与这个请求匹配的资源。
如果找到了，就直接返回缓存的资源，不再发起网络请求。
如果没找到，就发起网络请求，获取资源。
获取到资源后，把资源存到缓存仓库里，然后返回给浏览器。

通过这种方式，Service Worker实现了离线缓存和请求拦截。当用户离线时，Service Worker仍然可以从缓存里提供资源，保证网站的基本功能可用。

Cache Storage API 的更新策略

缓存更新是Service Worker里一个非常重要的话题。如果缓存里的资源过期了，或者网站发布了新的版本，就需要更新缓存。Cache Storage API提供了几种常见的更新策略：

Cache-First（缓存优先）

这是最简单的策略。Service Worker首先尝试从缓存里获取资源，如果找不到，才从网络获取。

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // 缓存命中
        if (response) {
          return response;
        }

        // 缓存未命中，从网络获取
        return fetch(event.request);
      })
  );
});

优点：速度快，离线可用。
缺点：如果缓存里的资源过期了，用户可能看到旧版本的内容。

Network-First（网络优先）

Service Worker首先尝试从网络获取资源，如果网络请求失败，才从缓存里获取。

self.addEventListener('fetch', event => {
  event.respondWith(
    fetch(event.request)
      .then(response => {
        // 检查是否收到了有效的响应
        if (!response || response.status !== 200 || response.type !== 'basic') {
          return response;
        }

        // 克隆 Response 对象，因为 Response 对象只能读取一次
        const responseToCache = response.clone();

        caches.open(cacheName)
          .then(cache => {
            cache.put(event.request, responseToCache);
          });

        return response;
      })
      .catch(error => {
        // 网络请求失败，从缓存获取
        return caches.match(event.request);
      })
  );
});

优点：可以保证用户总是看到最新版本的内容。
缺点：速度慢，离线不可用（除非网络请求失败）。

Cache, then Network（缓存，然后网络）

Service Worker首先从缓存里获取资源，然后发起一个网络请求更新缓存。这种策略可以保证用户尽快看到内容，同时又能及时更新缓存。

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // 先返回缓存中的资源
        return response || fetch(event.request);
      })
  );

  // 同时更新缓存
  event.waitUntil(
    fetch(event.request)
      .then(response => {
        // 检查是否收到了有效的响应
        if (!response || response.status !== 200 || response.type !== 'basic') {
          return;
        }

        // 克隆 Response 对象，因为 Response 对象只能读取一次
        const responseToCache = response.clone();

        caches.open(cacheName)
          .then(cache => {
            cache.put(event.request, responseToCache);
          });
      })
  );
});

优点：速度快，可以及时更新缓存。
缺点：可能会出现短暂的内容不一致。

Network, then Cache（网络，然后缓存）

Service Worker首先尝试从网络获取资源，如果网络请求成功，就更新缓存；如果网络请求失败，就从缓存里获取资源。

self.addEventListener('fetch', event => {
  event.respondWith(
    fetch(event.request)
      .then(response => {
        // 检查是否收到了有效的响应
        if (!response || response.status !== 200 || response.type !== 'basic') {
          return response;
        }

        // 克隆 Response 对象，因为 Response 对象只能读取一次
        const responseToCache = response.clone();

        caches.open(cacheName)
          .then(cache => {
            cache.put(event.request, responseToCache);
          });

        return response;
      })
      .catch(error => {
        // 网络请求失败，从缓存获取
        return caches.match(event.request);
      })
  );
});

优点：可以保证用户总是看到最新版本的内容，同时又能保证离线可用。
缺点：速度慢。

Stale-While-Revalidate（过时内容，同时验证）

这个策略有点复杂，但也很强大。Service Worker首先从缓存里获取资源，同时发起一个网络请求更新缓存。当网络请求返回时，会更新缓存，但不会立即更新页面。下次请求时，才会使用更新后的缓存。

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // 如果缓存中有，先返回缓存中的内容
        const fetchPromise = fetch(event.request).then(networkResponse => {
          caches.open(cacheName).then(cache => {
            cache.put(event.request, networkResponse.clone());
            return networkResponse;
          });
        });
        return response || fetchPromise;
      })
  );
});

优点：速度快，可以及时更新缓存，用户体验好。
缺点：实现起来比较复杂。

选择合适的更新策略

选择哪种更新策略取决于你的应用场景。一般来说：

对于静态资源（比如CSS，JS，图片），可以使用Cache-First或者Stale-While-Revalidate策略。
对于动态数据（比如API请求），可以使用Network-First或者Network, then Cache策略。
对于需要实时更新的数据，可以使用Network-Only策略（不使用缓存）。

缓存的版本控制

当你的网站发布了新的版本，你需要更新缓存。最简单的方法就是修改缓存的名称。

const cacheName = 'my-awesome-cache-v2'; // 更新缓存名称

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(cacheName)
      .then(cache => {
        return cache.addAll(urlsToCache);
      })
  );
});

self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.map(cacheName => {
          if (cacheName !== this.cacheName) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

这段代码的流程是这样的：

当Service Worker安装时，会创建一个新的缓存仓库，名称为my-awesome-cache-v2。
当Service Worker激活时，会删除旧的缓存仓库（名称为my-awesome-cache-v1）。

通过这种方式，可以保证用户总是使用最新版本的缓存。

表格总结各种缓存策略

策略	优点	缺点	适用场景
Cache-First	速度快，离线可用	如果缓存里的资源过期了，用户可能看到旧版本的内容	静态资源（CSS，JS，图片）
Network-First	可以保证用户总是看到最新版本的内容	速度慢，离线不可用（除非网络请求失败）	动态数据（API请求）
Cache, then Network	速度快，可以及时更新缓存	可能会出现短暂的内容不一致	静态资源，希望尽快展示内容，并异步更新
Network, then Cache	可以保证用户总是看到最新版本的内容，同时又能保证离线可用	速度慢	动态数据，希望总是展示最新数据，并提供离线支持
Stale-While-Revalidate	速度快，可以及时更新缓存，用户体验好	实现起来比较复杂	静态资源，对实时性要求不高，但希望用户能尽快看到内容，并异步更新

一些实用的技巧

使用Chrome DevTools的Application面板来调试Service Worker和Cache Storage。
使用workbox库来简化Service Worker的开发。
定期清理过期的缓存，避免占用过多的存储空间。
在Service Worker里添加错误处理，避免出现意外情况。

结语

Cache Storage API是Service Worker里一个非常重要的组成部分。掌握了它的使用方法，你就可以轻松实现离线缓存和请求拦截，提升网站的性能和用户体验。希望今天的讲座对你有所帮助！咱们下期再见！

发表回复 取消回复

发表回复取消回复