原文地址
https://web.dev/service-workers-cache-storage/
Service workers
Service workers内置在浏览器中，由开发者负责创建的一点额外JavaScript代码控制。开发者可以将它与构成实际web应用程序的其他文件一起部署。
Service workers有一些特殊的权力。在其他任务中，它耐心地等待你的web应用发出一个传出请求，然后通过截获它而开始行动。Service workers如何处理这个截获的请求取决于开发者。
对于某些请求，最好的做法可能只是允许请求继续传输到网络上，就像根本没有Service workers一样。
不过，对于其他请求，您可以利用比浏览器的HTTP缓存更灵活的功能，并返回可靠的快速响应，而不必担心网络。这就需要使用另一个功能：Cache Storage API。
The Cache Storage API
Cache Storage API 为开发人员提供了对缓存内容的完全控制，从而拓宽了可能性。
其他缓存功能
仍然建议您在web服务器上配置缓存控制头，即使您知道您正在使用Cache Storage API。比如：Cache Control:no Cache 和 Control:max age=31536000。
使用Cache Storage API 来缓存数据时，浏览器默认检查HTTP缓存中的现有条目，如果找到则使用这些条目。
Cache Storage API 可以做很多事情，一些仅使用HTTP缓存很难或不可能实现的，包括：
- 对缓存内容使用“后台刷新”方法，称为stale-while-revalidate。
- 对要缓存的最大资产数施加上限，并实现自定义过期策略以在达到该限制后删除项目。
- 比较以前缓存的和新的网络响应，以查看是否有任何更改，并允许用户在数据实际更新时更新内容（例如，使用按钮）
API nuts and bolts
关于API的设计，需要记住一些事情：
- 在读写这些缓存时，Requiest 对象被用作唯一键。为了方便起见，您可以传入一个URL字符串，如'https://example.com/index.html'作为键而不是实际的请求对象，API将自动为您处理。
- Response 对象被用作返回值。
- 缓存数据时，给定响应上的缓存控制头将被忽略。没有自动的、内置的过期或新鲜度检查，一旦您将一个项目存储在缓存中，它将一直存在，直到您的代码显式删除它。（有一些库可以为您简化缓存维护。本系列稍后将介绍这些问题。如：Workerbox）
- 与LocalStorage等较旧的同步API不同，所有Cache Storage API 操作都是异步的。
