1、前言
作為一個前端，了解http緩存是非常必要，它不僅是面試的必要環節，也更是實戰開發中必不可少需要了解的知識點，本文作者將從緩存的概念講到如何在業務中設計一個合理的緩存架構，帶你一步一步解開http緩存的神秘面紗。
2、http緩存定義
當客戶端向服務器請求資源時，會先抵達瀏覽器緩存，如果瀏覽器有“要請求資源”的副本，就可以直接從瀏覽器緩存中提取而不是從原始服務器中提取這個資源。http緩存一般針對GET請求，POST請求一般不會緩存，因為POST請求執行的任務都是對服務器產生副作用或者非冪等性的任務，既然要改變服務器資源，自然請求是要進入服務器進行處理的。緩存帶來的好處是巨大的，減少了http請求，自然也就減少的服務端壓力，並且增加了資源的訪問速度，但是胡亂使用緩存，將會帶來資源的不及時更新，甚至資源更新錯位，災難也是巨大的。
http緩存分為強緩存和協商緩存，下面帶大家一一了解兩種緩存機制。
3、強緩存
3.1、強緩存定義
如果命中緩存，直接從緩存中拿數據，請求不會經過服務器，返回的http狀態碼為200(from disk cache)
下面給一張流程圖來說明強緩存的請求過程，為了方便假設瀏覽器存在一個緩存數據庫（其實就是disk磁盤，緩存數據存放的地方）。
仔細看上面的流程圖，強緩存的最大特點就是在命中緩存的情況下不會經過服務器，而是直接返回。
3.2、Http頭Expires/Cache-Control設置強緩存
Cache-Control里面存在多個屬性來控制緩存，設置強緩存即設置資源的有效期，屬性為max-age.
下面使用Express給大家演示一下
app.get('/script1.js', function (req, res, next) {
// res.header('Cache-Control', 'must-revalidate, max-age=600')
// res.header('Content-Type', 'text/html')
res.header('Cache-Control', 'max-age=20')
res.sendFile(__dirname + '/script.js')
})
Expires和max-age都是用於控制緩存的生命周期。不同的是Expires指定的是過期的具體時間，例如Sun, 21 Mar 2027 08:52:14 GMT，而max-age指定的是生命時長秒數315360000。
區別在於Expires是 HTTP/1.0 的中的標准，而max-age是屬於Cache-Control的內容，是 HTTP/1.1 中的定義的。但為了想向前兼容，這兩個屬性仍然要同時存在。max-age是要優先於Expires的。
4、協商/對比緩存
4.1、定義
協商緩存與強制緩存的不同之處在於，協商緩存每次讀取數據時都需要跟服務器通信，並且會增加緩存標識。在第一次請求服務器時，服務器會返回資源，並且返回一個資源的緩存標識，一起存到瀏覽器的緩存數據庫。當第二次請求資源時，瀏覽器會首先將緩存標識發送給服務器，服務器拿到標識后判斷標識是否匹配，如果不匹配，表示資源有更新，服務器會將新數據和新的緩存標識一起返回到瀏覽器；如果緩存標識匹配，表示資源沒有更新，並且返回 304 狀態碼，瀏覽器就讀取本地緩存服務器中的數據。
協商緩存的最大特點是要經過服務器驗證的，下面我們來講解協商緩存的驗證流程。
第一次訪問：
再次訪問：
還是給一張流程圖來說明。（圖是盜的，協商緩存也可以成為對比緩存，圖中的對比緩存就是協商緩存）
4.2、協商緩存如何驗證
第一次請求將response header的Last-Modified和Etag存起來，在第二次請求通過request header的If-Modified-Since和If-None-Match傳到服務端進行驗證，如果命中緩存，返回304，不帶返回的數據，瀏覽器自動從緩存中獲取數據資源，若未命中緩存返回200，帶上數據資源。
** Last-Modified：**
服務器在響應請求時，告訴瀏覽器資源的最后修改時間。
** If-Modified-Since：**
再次請求服務器時，通過此字段通知服務器上次請求時，服務器返回的資源最后修改時間。
服務器收到請求后發現有頭If-Modified-Since 則與被請求資源的最后修改時間進行比對。
若資源的最后修改時間大於If-Modified-Since，說明資源又被改動過，則響應整片資源內容，返回狀態碼200；
若資源的最后修改時間小於或等於If-Modified-Since，說明資源無新修改，則響應HTTP 304，告知瀏覽器繼續使用所保存的cache。
** Etag / If-None-Match（優先級高於Last-Modified / If-Modified-Since） **
** Etag：**
服務器響應請求時，告訴瀏覽器當前資源在服務器的唯一標識（生成規則由服務器決定）。
** If-None-Match：**
再次請求服務器時，通過此字段通知服務器客戶段緩存數據的唯一標識。
服務器收到請求后發現有頭If-None-Match 則與被請求資源的唯一標識進行比對，
不同，說明資源又被改動過，則響應整片資源內容，返回狀態碼200；
相同，說明資源無新修改，則響應HTTP 304，告知瀏覽器繼續使用所保存的cache。
4.3、Http頭如何設置協商緩存
在強緩存那一節說到使用Cache-Control的max-age來設置資源過期時間，那么當max-age=0的時候呢，自然瀏覽器第一時間發現資源過期，request header就會帶着If-Modified-Since和If-None-Match去服務端驗證。
所以設置response header為：
Cache-Control: max-age=0
就可以觸發協商緩存了，其實Cache-Control中還有兩個屬性都可以設置協商緩存 must-revalidate和no-cache
must-revalidate的意義為必須進行驗證，但是它一般是和max-age一起使用的，不會單獨使用，
Cache-Control: must-revalidate, max-age=600
該頭信息意義就是在資源有效期過后必須進行驗證， 與只設置max-age=600的區別是，前面一個是MUST，而后面一個是SHOULD，理論上來說它們的效果是一致的。
no-cache的意義千萬不能理解為不緩存，下面兩段代碼的意義是一樣的，即請求必須進行驗證，才可以使用緩存資源，注意是MUST
Cache-Control: no-cache
Cache-Control: must-revalidate, max-age=0
如果要不緩存，每次都請求新的資源應該使用
Cache-Control: no-store
5、關於緩存的Http頭總結
5.1、"no-cache", "no-store", "must-revalidate"
Cache-Control字段可以設置的不僅僅是max-age存儲時間，還有其他額外的值可以填寫，甚至可以組合。主要使用的值有如下：
no-cache: 雖然字面意義是“不要緩存”。但它實際上的機制是，仍然對資源使用緩存，但每一次在使用緩存之前必須（MUST）向服務器對緩存資源進行驗證。
no-store: 不使用任何緩存
must-revalidate: 如果你配置了max-age信息，當緩存資源仍然新鮮（小於max-age）時使用緩存，否則需要對資源進行驗證。所以must-revalidate可以和max-age組合使用Cache-Control: must-revalidate, max-age=60
有趣的事情是，雖然no-cache意為對緩存進行驗證，但是因為大家廣泛的錯誤的把它當作no-store來使用，所以有的瀏覽器也就附和了這種設計。這是一個典型的劣幣驅逐良幣。
5.2、Expires VS. max-age
Expires和max-age都是用於控制緩存的生命周期。不同的是Expires指定的是過期的具體時間，例如Sun, 21 Mar 2027 08:52:14 GMT，而max-age指定的是生命時長秒數315360000。
區別在於Expires是 HTTP/1.0 的中的標准，而max-age是屬於Cache-Control的內容，是 HTTP/1.1 中的定義的。但為了想向前兼容，這兩個屬性仍然要同時存在。
但有一種更傾向於使用max-age的觀點認為Expires過於復雜了。例如上面的例子Sun, 21 Mar 2027 08:52:14 GMT，如果你在表示小時的數字缺少了一個0，則很有可能出現出錯；如果日期沒有轉換到用戶的正確時區，則有可能出錯。這里出錯的意思可能包括但不限於緩存失效、緩存生命周期出錯等。
5.3、Etag VS. Last-Modified
Etag和Last-Modified都可以用於對資源進行驗證，而Last-Modified顧名思義，表示資源最后的更新時間。
我們把這兩者都成為驗證器（Validators），不同的是，Etag屬於強驗證（Strong Validation），因為它期望的是資源字節級別的一致；而Last-Modified屬於弱驗證（Weak Validation），只要資源的主要內容一致即可，允許例如頁底的廣告，頁腳不同。
根據RFC 2616標准中的13.3.4小節，一個使用HTTP 1.1標准的服務端應該（SHOULD）同時發送Etag和Last-Modified字段。同時一個支持HTTP 1.1的客戶端，比如瀏覽器，如果服務端有提供Etag的話，必須（MUST）首先對Etag進行Conditional Request（If-None-Match頭信息）；如果兩者都有提供，那么應該（SHOULD）同時對兩者進行Conditional Request（If-Modified-Since頭信息）。如果服務端對兩者的驗證結果不一致，例如通過一個條件判斷資源發生了更改，而另一個判定資源沒有發生更改，則不允許返回304狀態。但話說回來，是否返回還是通過服務端編寫的實際代碼決定的。所以仍然有操縱的空間。
5.4、max-age=0 VS. no-cache
max-age=0是在告訴瀏覽器，資源已經過期了，你應該（SHOULD）對資源進行重新驗證了；而no-cache則是告訴瀏覽器在每一次使用緩存之前，你必須（MUST）對資源進行重新驗證。
區別在於，SHOULD是非強制性的，而MUST是強制性的。在no-cache的情況下，瀏覽器在向服務器驗證成功之前絕不會使用過期的緩存資源，而max-age=0則不一定了。雖然理論上來說它們的效果應該是一致的。
5.5、public VS. private
要知道從服務器到瀏覽器之間並非只有瀏覽器能夠對資源進行緩存，服務器的返回可能會經過一些中間（intermediate）服務器甚至甚至專業的中間緩存服務器，還有CDN。而有些請求返回是用戶級別、是私人的，所以你可能不希望這些中間服務器緩存返回。此時你需要將Cache-Control設置為private以避免暴露。
6、緩存實戰
前面寫了很多緩存的基礎知識，那么如何設計一個可靠的緩存規則，這個其實得根據你的實際需求而定。
比如某個資源永遠不會改變，比如某些第三方庫（一般都放CDN做優化了），或者某些圖片，比如百度的圖片，就讓它們永久緩存着吧，設置一個最大的max-age
Cache-Control: max-age=31536000
其他的資源可根據下面這張決策樹來進行設置
7、memory cache
memory cache叫做內存緩存，根據操作系統的常理，先讀內存，后讀硬盤。內存存儲較小，一般只存儲臨時性文件。
“內存緩存”中主要包含的是當前文檔中頁面中已經抓取到的資源（預請求資源）。例如頁面上已經下載的樣式、腳本、圖片等。我們不排除頁面可能會對這些資源再次發出請求，所以這些資源都暫存在內存中，當用戶結束瀏覽網頁並且關閉網頁時，內存緩存的資源會被釋放掉。
這其中最重要的緩存資源其實是preloader相關指令（例如
）下載的資源。總所周知preloader的相關指令已經是頁面優化的常見手段之一，而通過這些指令下載的資源也都會暫存到內存中。根據一些材料，如果資源已經存在於緩存中，則可能不會再進行preload。
memory cache 機制保證了一個頁面中如果有兩個相同的請求 (例如兩個 src 相同的 
，兩個 href 相同的
)都實際只會被請求最多一次，避免浪費。
需要注意的事情是，內存緩存在緩存資源時並不關心返回資源的HTTP緩存頭Cache-Control是什么值，同時資源的匹配也並非僅僅是對URL做匹配，還可能會對Content-Type，CORS等其他特征做校驗
這個應該是瀏覽器做的一種優化，緩存也只是暫時的。
8、瀏覽器可能會限制Cache-Control頭無效
** 參考文章： **
https://zhuanlan.zhihu.com/p/28113197#comments
https://www.cnblogs.com/chenqf/p/6386163.html