运行时缓存是指“按需”逐步将响应添加到缓存中。 虽然运行时缓存对当前 这有助于提高日后对同一网址的请求的可靠性。
浏览器的 HTTP 缓存就是一种运行时缓存；它仅会填充 。但通过 Service Worker，您可以实现 HTTP 缓存所能提供的运行时缓存。
巧用策略
这与预先缓存（它始终会尝试 从缓存中提供一组预定义的文件），则运行时缓存可以结合使用 支持通过多种方式访问网络和缓存。一般来说，每种组合 称为缓存策略关键缓存策略包括：
- 网络优先
- 缓存优先
- 过时重新验证
网络优先
在此方法中，Service Worker 首先尝试从 网络。如果网络请求成功，那就太棒了！响应返回到 而响应的副本则存储在 Cache Storage API - 创建新条目，或更新同一条目的 网址。
如果网络请求完全失败，或者 用时太长 以返回响应，则从缓存中返回的最新响应 。
缓存优先
缓存优先策略实际上与网络优先策略正好相反。在本课中， 方法时，当 Service Worker 拦截请求时，它会先使用缓存 Storage API，用于查看是否有可用的缓存响应。如果有， 该响应将返回给 Web 应用。
但如果缓存未命中，则 Service Worker 会转到网络 并尝试在其中检索响应。假设网络请求是 请求成功后，系统会将该文件返回给您的 Web 应用，并在缓存中保存一份副本。这个 下次请求缓存副本时， 都会出现相同的网址
过时重新验证
过时-重新验证属于一种混合模式。使用它时，您的服务 工作器将立即检查是否有缓存的响应，如果找到缓存响应，则传递 将其传回您的 Web 应用。
在此期间，无论是否存在缓存匹配项，您的服务 工作器还会发出网络请求响应。这个 响应用于更新之前缓存的响应。如果初始缓存 检查失败，网络响应的副本也会传回您的网络 应用。
为什么应该使用 Workbox？
这些缓存策略相当于 在您自己的 Service Worker 中一次又一次地重写。你不必借助 Workbox 将它们打包在一起， 策略库 准备连接到 Service Worker。
Workbox 还提供版本控制功能，让您可以自动 expire（过期） 缓存条目，或者在以下情况下通知您的 Web 应用： 更新 先前缓存的条目发生的情况
应该使用哪些策略缓存哪些资产？
可将运行时缓存视为对预缓存的补充。如果您 资源已经预先缓存，就大功告成了。 在运行时缓存对于任何相对复杂的 Web 应用 但不会预先缓存所有内容。
较大的媒体文件，由第三方主机（例如 CDN）提供的资源， 或 API 响应，这只是一些无法 进行有效预缓存使用开发者工具中的“Network”面板来确定请求 并考虑如何权衡哪些因素， 新鲜度还是可靠性比较合适。
使用过时进行重新验证，优先考虑可靠性而不是新鲜度
由于过时重新验证策略会返回缓存的响应， （通过第一个请求填充缓存之后），您将结束 。它随附 返回可能过时的响应数据 原本应从网络中检索到的数据。使用此策略的效果最佳 或初始 API 响应 即使您知道立即显示某些内容是关键，即使 如果它是较旧的值，则会发生此错误。
使用网络优先，优先保证新鲜度而非可靠性
从某种意义上说，使用网络优先的策略意味着在战斗中承受失败 网络 - 优先级较高，但也带来了不确定性 可靠性。对于某些类型的素材资源，查看新的回复 获取过时的信息。在以下情况下，您可能希望保持新鲜度 针对频繁更新的文章文本发出 API 请求， 实例。
在 Service Worker 中使用网络优先策略，而不仅仅是 与广告网络直接对决的 好处在于 ，即使响应可能已过时也是如此。你不会 而且至少在离线状态下也能可靠。
对版本化网址使用缓存优先
在缓存优先策略中，条目一旦被缓存，便永远不会更新。为此
因此，请确保只将其用于您确定不太可能
更改。尤其适用于包含版本控制的网址
信息（即同样也应提供
Cache-Control: max-age=31536000 响应标头。