前端開發人員的一個常見誤區就是，看到下圖這種沒有附帶 cache control 的 HTTP 響應頭部欄位，就誤認為 HTTP 快取已經被禁用了，其實不然。

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

省略 Cache-Control 響應標頭不會禁用 HTTP 快取！ 相反，瀏覽器有效地猜測哪種型別的快取行為對給定型別的內容最有意義。

版本化的 URL 是一種很好的做法，因為它們可以更容易地使快取的響應無效。

在響應對包含`指紋(fingerprint)`或版本資訊且其內容永遠不會更改的 URL 的請求時，請將 Cache-Control: max-age=31536000 新增到您的響應中。

設定這個值告訴瀏覽器，當它需要在接下來一年的任何時間（31,536,000 秒；支援的最大值）載入相同的 URL 時，它可以立即使用 HTTP 快取中的值，而無需向網路請求遠端的 Web 伺服器，從而立即獲得了避免網路帶來的可靠性和速度。

像 webpack 這樣的構建工具可以[自動](https://webpack.js.org/guides/caching/#output-filenames)將雜湊指紋分配給 asset URL.

不幸的是，實際應用場景中，並非載入的所有 URL 都是版本化的。 或者也許無法在部署 Web 應用程式之前包含構建步驟，因此無法將雜湊值新增到資產 URL。 而且每個 Web 應用程式都需要 HTML 檔案——這些檔案幾乎永遠不會包含版本資訊，因為如果客戶需要記住要訪問的 URL 是 https://example.com，那麼沒有人會願意使用帶有版本資訊的 Web 應用程式，比如 /index.13def12.html.

單獨的 HTTP 快取不足以完全避開網路，需要藉助 Service Worker 的幫助。

以下 Cache-Control 值可以幫助開發人員微調未版本化 URL 的快取位置和方式：

- no-cache：這指示瀏覽器在每次使用 URL 的快取版本之前都必須與伺服器重新驗證。
- no-store：這指示瀏覽器和其他中間快取（如 CDN）永遠不要儲存檔案的任何版本。
- private：瀏覽器可以快取檔案，但中間快取不能。
- public：響應可以由任何快取儲存。

Web Server 設定快取響應欄位的一些推薦方案

相關文章