共计 969 个字符，预计需要花费 3 分钟才能阅读完成。
本文基于下列的表格进行探讨。
场景 1：Long-term caching (Cache, falling back to network)
- 当缓存资源无效时（<= 30 天）：Service Worker 立刻返回缓存的资源，无需拜访网络。
- 当缓存资源过期（> 30 天）时：Service Worker 去网络获取资源。浏览器在其 HTTP 缓存中没有资源的正本，因而它在服务器端获取资源。
毛病：在这种状况下，HTTP 缓存提供的价值较小，因为当 Service Worker 中的缓存过期时，浏览器总是会将申请传递给服务器端。
场景 2：Medium-term caching (Stale-while-revalidate)
- 当缓存资源无效时（<= 1 天）：Service Worker 立刻返回缓存的资源，并去网络获取资源。浏览器在其 HTTP 缓存中有资源的正本，因而它将该正本返回给服务工作者。
- 当缓存资源过期（> 1 天）：Service Worker 立刻返回缓存的资源，并去网络获取资源。浏览器在其 HTTP 缓存中没有资源的正本，因而它会在服务器端获取资源。
毛病：Service Worker 须要额定的缓存革除来笼罩 HTTP 缓存，以便充分利用“从新验证”步骤。
场景 3：Short-term caching (Network falling back to cache)
- 当缓存的资源无效时（<= 10 分钟）：Service Worker 去网络获取资源。浏览器在其 HTTP 缓存中有资源的正本，因而它会将其返回给服务工作者，而无需进入服务器端。
- 当缓存资源过期（> 10 分钟）：Service Worker 立刻返回缓存的资源，并去网络获取资源。浏览器在其 HTTP 缓存中没有资源的正本，因而它会在服务器端获取资源。
与 Medium 缓存场景相似，Service Worker 须要额定的缓存革除逻辑来笼罩 HTTP 缓存，以便从服务器端获取最新资源。
在所有场景下，Service Worker 缓存在网络不稳固的状况下依然能够返回缓存的资源。另一方面，当网络不稳固或宕机时，HTTP 缓存是不牢靠的。
总之，Service Worker 缓存逻辑不须要与 HTTP 缓存到期逻辑保持一致。如果可能，在 service worker 中应用更长的过期逻辑来授予 service worker 更多的控制权。
HTTP 缓存依然施展着重要作用，但在网络不稳固或宕机时它并不牢靠。
正文完
