本文譯自: 這裡
本文已同步到我的部落格
引言
緩存利用得當的話，有很大益處，比如節省帶寬，降低伺服器壓力等，但是很多網站沒能夠很好地利用緩存，造成一些互相依賴的資源出現不同步的情況。
關于緩存的處理方案主要可以分為以下兩種：
方案一：資源内容保持不變+超長的max-age
Cache-Control: max-age=31536000
- 這個url對應的資源永遠保持不變
- 浏覽器/CDN可以将該資源緩存很久
- 對于沒有超過max-age的緩存内容可以直接使用，而不必再向伺服器請求
如下圖所示：
在這種情況下，一個url對應的資源應該是一直保持不變的，如果我們想更新資源，隻能通過更改url的方式來實作：
<script src="/script-f93bca2c.js"></script>
<link rel="stylesheet" href="/styles-a837cb1e.css" target="_blank" rel="external nofollow" >
<img src="/cats-0e9a2ef4.jpg" alt="…">
可以看到，url中帶有一串碼，該碼是與資源内容相關的，可以是版本号，修改日期，或者檔案内容的hash值。
大部分伺服器端的架構會有一些工具來讓這件事情變得簡單，
可是，這種方式并不适用于一些文章或者部落格之類的網站，這些網站的url不能通過版本号來管理，而且内容也是經常需要改變的。
方案二：内容可變，每次都需要伺服器再次校驗（revalidated）
Cache-Control: no-cache
- 這個url對應的資源是可變的
- 本地緩存隻有在伺服器驗證過是最新的之後才可以使用
（譯者注：可參照304場景）
如下圖所示：
注意：
no-cache
并不是指不緩存，而是指在使用緩存之前，必須首先向伺服器端确認資源是否為最新。
no-store
指不允許緩存。同樣的
must-revalidate
并非是指必須重新驗證，它的意思是，隻有當本地的緩存已經超過最長緩存時間時，才需要重新驗證。
在這種場景下，可以在響應頭中添加
ETag
或者
Last-Modified
。這樣，當用戶端在下次請求的時候，就會在請求頭中帶上這些資訊，分别對應的是
If-None-Match
和
If-Modified-Since
。伺服器端根據該辨別判斷資源是否為最新的，如果是，則傳回
304
狀态碼。
這種設定總是會需要一次網絡請求的（來驗證本地的緩存資源是否為最新），是以相比于第一種方式，增加了網絡請求。