本文主要講解瀏覽器端的快取，快取的作用是不言而喻的，能夠極大的改善網頁效能，提高使用者體驗。
快取這東西，第一次必須獲取到資源後，然後根據返回的資訊來告訴如何快取資源，可能採用的是強快取，也可能告訴客戶端瀏覽器是協商快取，這都需要根據響應的header內容來決定的。下面用兩幅圖來描述瀏覽器的快取是怎麼玩的，讓大家有個大概的認知。
瀏覽器第一次請求時：
瀏覽器後續在進行請求時：
從上圖可以知道，瀏覽器快取包含兩種型別，即強快取（也叫本地快取）和協商快取，瀏覽器在第一次請求發生後，再次請求時：
強快取與協商快取的區別，可以用下表來進行描述：
獲取資源形式狀態碼傳送請求到伺服器
強快取從快取取
200（from cache）
否，直接從快取取
協商快取從快取取
304（not modified）
是，正如其名，通過伺服器來告知快取是否可用
expires，這是http1.0時的規範；它的值為乙個絕對時間的gmt格式的時間字串，如mon, 10 jun 2015 21:31:12 gmt，如果傳送請求的時間在expires之前，那麼本地快取始終有效，否則就會傳送請求到伺服器來獲取資源
public：可以被所有的使用者快取，包括終端使用者和cdn等中間**伺服器。
private：只能被終端使用者的瀏覽器快取，不允許cdn等中繼快取伺服器對其快取。
注意：如果cache-control與expires同時存在的話，cache-control的優先順序高於expires
協商快取都是由伺服器來確定快取資源是否可用的，所以客戶端與伺服器端要通過某種標識來進行通訊，從而讓伺服器判斷請求資源是否可以快取訪問，這主要涉及到下面兩組header欄位，這兩組搭檔都是成對出現的，即第一次請求的響應頭帶上某個字段（last-modified或者etag），則後續請求則會帶上對應的請求字段（if-modified-since或者if-none-match），若響應頭沒有last-modified或者etag字段，則請求頭也不會有對應的字段。
last-modified/if-modified-since
二者的值都是gmt格式的時間字串，具體過程：
etag/if-none-match
這兩個值是由伺服器生成的每個資源的唯一標識字串，只要資源有變化就這個值就會改變；其判斷過程與last-modified/if-modified-since類似，與last-modified不一樣的是，當伺服器返回304 not modified的響應時，由於etag重新生成過，response header中還會把這個etag返回，即使這個etag跟之前的沒有變化。
這時，利用etag能夠更加準確的控制快取，因為etag是伺服器自動生成或者由開發者生成的對應資源在伺服器端的唯一識別符號。
last-modified與etag是可以一起使用的，伺服器會優先驗證etag，一致的情況下，才會繼續比對last-modified，最後才決定是否返回304。
盜用網上的一張圖，基本能描述使用者行為對快取的影響
上面說到，使用強快取時，瀏覽器不會傳送請求到服務端，根據設定的快取時間瀏覽器一直從快取中獲取資源，在這期間若資源產生了變化，瀏覽器就在快取期內就一直得不到最新的資源，那麼如何防止這種事情發生呢？
通過更新頁面中引用的資源路徑，讓瀏覽器主動放棄快取，載入新資源。
類似下圖所示：
這樣每次檔案改變後就會生成新的query值，這樣query值不同，也就是頁面引用的資源路徑不同了，之前快取過的資源就被瀏覽器忽略了，因為資源請求的路徑變了。
強快取和協商快取
對於一次已經有快取存在的請求來說 即之前已經發過針對這個資源的請求，在本地已經有快取 如果發起請求，那麼 首先會去找到快取資源的響應頭中的expires 過期時間 和cache control 控制快取的失效性 來判斷當前是否直接使用快取，如果當前時間還在expires之前，即快取仍未失效的情況下，...
強快取和協商快取
一 瀏覽器快取 1，第一次請求，無快取請求過程 流程如下所示 第二次請求，有快取請求的過程 流程如下圖所示 瀏覽器的快取分為二種，第一種的是強快取，另外一種是協商快取 2 強快取 定義 強快取在請求資源的時候，會從header裡面讀取是否是強快取，在有效的時間時間期內，從快取裡讀取不能從服務那裡讀取...
前端強快取和協商快取
快取是前端面試的乙個常見知識點，下面對於實際專案中如何進行快取的設定給出方案。瀏覽器快取是瀏覽器將使用者請求過的靜態資源儲存到電腦本地磁碟中，當再次訪問時，就可以直接從本地快取中載入而不需要去向伺服器請求了。但是快取也有缺點，如果服務端資源更新了，客戶端沒有強制重新整理的情況下，看到的內容還是舊的。...