现在来看看 Workbox 提供的缓存策略，主要有这几种：

cache-first,

cache-only,

network-first,

network-only,

stale-while-revalidate

在前面看到，实例化的时候会给 workbox 挂载一个 Strategies 的实例。提供上面一系列的缓存策略，但在实际调用中，使用的是 _getCachingMechanism，然后把整个策略类放到一参中，二参则提供了配置项，在每个策略类中都有 handle 方法的实现，最终也会调用 handle方法。那既然如此还搞个 _getCachingMechanism干嘛，直接返回策略类就得了，这个等下看。

先看下各个策略，这里就简单说下，可以参考离线指南，虽然会有一点不一样。

Cache-First

第一个 Cache-First, 它的 handle 方法：

const cachedResponse = await this.requestWrapper.match({request: event.request,
});return cachedResponse || await this.requestWrapper.fetchAndCache({request: event.request,waitOnCache: this.waitOnCache,
});

Cache-First策略会在有缓存的时候返回缓存，没有缓存才会去请求并且把请求结果缓存，这也是我们对于precache的策略。

Cache-only

然后是 Cache-only，它只会去缓存里拿数据，没有就失败了。

network-first

network-first 是一个比较复杂的策略，它接受 networkTimeoutSeconds 参数，如果没有传这个参数，请求将会发出，成功的话就返回结果添加到缓存中，如果失败则返回立即缓存。这种网络回退到缓存的方式虽然利于那些频繁更新的资源，但是在网络情况比较差的情况（无网会直接返回缓存）下，等待会比较久，这时候 networkTimeoutSeconds 就提供了作用，如果设置了，会生成一个setTimeout后被resolve的缓存调用，再把它和请求放倒一个 Promise.race 中，那么请求超时后就会返回缓存。

network-only

network-only，也比较简单，只请求，不读写缓存。

StaleWhileRevalidate

最后提供的策略是 StaleWhileRevalidate，这种策略比较接近 cache-first，代码如下：

const fetchAndCacheResponse = this.requestWrapper.fetchAndCache({request: event.request,waitOnCache: this.waitOnCache,cacheResponsePlugin: this._cacheablePlugin,
}).catch(() => Response.error());const cachedResponse = await this.requestWrapper.match({request: event.request,
});return cachedResponse || await fetchAndCacheResponse;

他们的区别在于就算有缓存，它仍然会发出请求，请求的结果会用来更新缓存，也就是说你的下一次访问的如果时间足够请求返回的话，你就能拿到最新的数据了。

可以看到离线指南中还提供了缓存然后访问网络再更新页面的方法，但这种需要配合主进程代码的修改，WorkBox 没有提供这种模式。

自定义缓存配置

回到在缓存策略里提到的，讲讲 _getCachingMechanism和缓存策略的参数。默认支持5个参数：'cacheExpiration', 'broadcastCacheUpdate', 'cacheableResponse', 'cacheName', 'plugins'，(当然你会发现还有几个参数不在这里处理，比如你可以传一个自定义的 requestWrapper, 前面提到的 waitOnCache 和 NetworkFirst 支持的 networkTimeoutSeconds)，先看一个完整的示例：

const workboxSW = new WorkboxSW();
const cacheFirstStrategy = workboxSW.strategies.cacheFirst({cacheName: 'example-cache',cacheExpiration: {maxEntries: 10,maxAgeSeconds: 7 * 24 * 60 * 60},broadcastCacheUpdate: {channelName: 'example-channel-name'},cacheableResponse: {stses: [0, 200, 404],headers: {'Example-Header-1': 'Header-Value-1','Example-Header-2': 'Header-Value-2'}}plugins: [// Additional Plugins]
});

大致可以认定的是 cacheExpiration 会用来处理缓存失效，cacheName 决定了 cache 的索引名，cacheableResponse 则决定了什么请求返回可以被缓存。

那么插件到底是怎么被处理，现在可以看_getCachingMechanism函数了，_getCachingMechanism函数处理了什么，它其实就是把 cacheExpiration，broadcastCacheUpdate,cacheabelResponse里的参数找到对应方法，传入参数实例化，然后挂在在封装后的wrapperOptions的plugins参数里，但是只是实例化了有什么用呢？这里有关键的一步：

options.requestWrapper = new RequestWrapper(wrapperOptions);

所以最终这些插件还是会在 RequestWrapper 里处理，这里的一些操作是我们之前没有提到的，来看下 RequestWrapper 里怎么处理的。

看下 RequestWrapper 的构造函数，取其中涉及到 plugins 的部分：

constructor({cacheName, cacheId, plugins, fetchOptions, matchOptions} = {}) {this.plugins = new Map();if (plugins) {isArrayOfType({plugins}, 'object');plugins.forEach((plugin) => {for (let callbackName of pluginCallbacks) {if (typeof plugin[callbackName] === 'function') {if (!this.plugins.has(callbackName)) {this.plugins.set(callbackName, []);} else if (callbackName === 'cacheWillUpdate') {throw ErrorFactory.createError('multiple-cache-will-update-plugins');} else if (callbackName === 'cachedResponseWillBeUsed') {throw ErrorFactory.createError('multiple-cached-response-will-be-used-plugins');}this.plugins.get(callbackName).push(plugin);}}});}
}

plugins是一个Map，默认支持以下几种Key：cacheDidUpdate, cacheWillUpdate, fetchDidFail, requestWillFetch, cachedResponseWillBeUsed。可以理解为 requestWrapper 提供了一些hooks或者生命周期，而插件就是在 hook 上进行一些处理。

这里举个缓存失效的例子看看怎么处理：

首先我们需要实例化CacheExpirationPlugin，CacheExpirationPlugin没有构造函数，实例化的是CacheExpiration，然后在this上添加maxEntries，maxAgeSeconds。所有的 hook 方法实现都放在了 CacheExpirationPlugin，提供了两个 hook: cachedResponseWillBeUsed 和 cacheDidUpdate，cachedResponseWillBeUsed 会在 RequestWrapper的match中执行，cacheDidUpdate 在 fetchAndCache中 执行。

这里可以看出，每个plugin其实就是对hook或者生命周期调用的具体实现，在把response扔到cache里之后，调用了插件的cacheDidUpdate方法，看下CacheExpirationPlugin中的cacheDidUpdate：

async cacheDidUpdate({cacheName, newResponse, url, now} = {}) {isType({cacheName}, 'string');isInstance({newResponse}, Response);if (typeof now === 'undefined') {now = Date.now();}await this.updateTimestamp({cacheName, url, now});await this.expireEntries({cacheName, now});
}

那么关键就是更新时间戳和失效条数，如果设置了更新时间戳会怎么样呢，在请求的时候，runtimecache也会添加到IndexedDB，值存入的是一个对象，包含了一个url和时间戳。

这个时间戳怎么生效，CacheExpirationPlugin提供了另外一个方法，cachedResponseWillBeUsed:

cachedResponseWillBeUsed({cachedResponse, cachedResponse, now} = {}) {if (this.isResponseFresh({cachedResponse, now})) {return cachedResponse;}return null;
}

RequestWrapper中的match方法会默认从cache里取，取到的是当时的完整 response, 在cache的 response 里的 headers 里取到 date，然后把当时的date加上 maxAgeSecond 和 现在的时间比， 如果小于了就返回 false，那么自然会去发起请求了。

CacheableResponsePlugin用来控制 fetchAndCache 里的 cacheable，它设置了一个 cacheWillUpdate，可以设置哪些 http status 或者 headers 的 response 要缓存，做到更精细的缓存操作。

如何配置我的缓存

离线指南已经提供了一些缓存方式，在 workbox 中，可以大致认为，有一些资源会直接影响整个应用的框架能否显示的（开发应用的 JS，CSS 和部分图片）可以做 precache，这些资源一般不存在“异步”的加载，它们如果不显示整个页面无法正常加载。

那他们的更新策略也很简单，一般这些资源的更新需要发版，而在这里用更新sw文件更新。

对于大部分无状态（注意无状态）数据请求，推荐StaleWhileRevalidate方式或者缓存回退，在某些后端数据变化比较快的情况下，添加失效时间也是可以的，对于其它（业务图片）需求，cache-first比较适用。

最后需要讨论的是页面和有状态的请求，页面是一个比较复杂的情况，页面如果是纯静态的，那么可以放入precache。但要注意，如果我们的页面不是打包工具生成的，页面文件很可能不在dist目录下，那么怎么追踪变化呢，这里推荐一种方式，我们的页面往往有一个模版，和一个json串配置hash变量，那么你可以添加这种模式：

templatedUrls: {path: ['.../xxx.html','.../xxx.json']
}

如果没有json，就需要关联所有可能影响生成页面的数据了，那么这些文件的变化都会改变最后生成的sw文件。

如果你在页面上有一些动态信息（比如用户信息等等），那就比较麻烦了，推荐使用 network-first 配合一个合适的失败时间，毕竟大家都不希望用户登录了另一个账号，显示的还是上一个账号，这同样适用于那些使用cookie（有状态）的请求，这些请求也推荐你添加失效策略，和失败状态。

永远记住你的目标，让用户能够更快的看到页面，但不要给用户一个错误的页面。