我试图弄清楚服务 worker 如何处理响应中的缓存 header 。我现在已经实现了几个服务 worker ，但从来不必担心缓存标题，项目应该缓存多长时间等等。我现在在企业生产站点上实现它，这些东西实际上很重要。
基本上在使用 Service Worker 时，是否完全绕过了 http 缓存？
那么我是否需要构建一个框架来处理资源过期/失效，就像过去为我们做的 http 缓存一样？还是我在胡说八道？
如果有人可以对此进行一些说明，那将非常有帮助。在我看来，有 3 种可能的情况:
一种)。网络请求 => Service worker fetch =>(浏览器缓存？)<=> 服务器
B)。网络请求 <=>(浏览器缓存？)<=> Service worker fetch <=> Server
C)。网络请求 => 服务 worker 获取 <=> 服务器
我已经在本地测试过了，似乎是 C)。是正确的实现，我们开发人员为此牺牲了缓存头/持续时间抽象来进行控制。
我对此很好，只是希望在我离开并构建一个框架来读取和尊重服务 worker 中的缓存 header 之前澄清一下。
最佳答案
A) 是正确的模型。如果 service worker 控制了一个页面，所有的网络请求都会触发 fetch在查询浏览器缓存或网络之前服务 worker 的事件处理程序。
反过来，任何时候 Service Worker 发出网络请求，或者明确地通过 fetch()或隐式通过 cache.add()/cache.addAll() ，首先会查询浏览器的“传统”缓存以获得响应。只有在浏览器缓存中没有有效响应时，才会向服务器发出网络请求。
这有时对您有利，如果您不期望这种行为，有时会使您暴露于微妙的错误。
在 https://jakearchibald.com/2016/caching-best-practices/ 上有关于这种交互的非常详细的解释。 ，专门涵盖things to avoid和 ways to take advantage of this behavior .
关于browser-cache - Service Worker 响应缓存 header ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42301123/