本文基於下列的表格進行討論。

![](https://img-blog.csdnimg.cn/img_convert/f5d4813ccea0b56ced7a994a8623d995.png)

# 場景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 快取仍然發揮著重要作用，但在網路不穩定或當機時它並不可靠。

Service Worker Cache 和 HTTP Cache 聯合使用的場景討論

相關文章