很早就想梳理一下瀏覽器的快取機制了，一直沒有時間，實際是上懶啦(*^▽^*)，你知道的，人都有惰性，本大神只是個假神o(´^｀)o，也不例外。
難得今天較為清閒，還是借鑑一下成功人的經驗，梳理一下吧，好記性不如爛筆頭，說不定哪次面試遇到了呢
在前端開發中，效能是乙個永恆的話題，沒有最好，只有更好。判斷乙個**效能好壞，乙個直入眼觀的即是網頁的反應速度，有乙個方式就是使用快取，乙個優秀的快取策略可以縮短網頁請求的時間，減少延遲，並且網頁可以重複利用，還可以減少頻寬，降低網路負荷。
1：為什麼需要快取？
a：快取可以減少使用者等待時間，提公升使用者體驗
b：減少網路頻寬消耗
c：降低伺服器壓力
note：快取使用不當，也會造成『髒資料』問題
2：常見的快取型別
強快取 -
expires伺服器端設定，表示該資源的過期時間，會有弊端，客戶端時間和伺服器時間不一致的問題。
cache-control：max-age表示快取資源的最大生命週期，單位是秒
所以expires 結合 cache-control 一起使用，大型**中一般比較適用
協商快取-
last-modified：值為資源的最後更新時間，隨伺服器response返回
if-modified-since：通過比較兩個時間來判斷資源在兩次請求期間是否有過修改，如果沒有，則命中協商快取
etag：表示資源內容的唯一標識，即資源的訊息摘要
if-none-match：伺服器通過比較請求頭中的if-none-match與當前資源的etag是否一致來判斷資源是否在兩次請求期間有過修改
3：快取流程圖標：
圖示解析
a：瀏覽器會先檢測強快取型別（cache-control 或者 expires）是否有效；命中直接瀏覽器本地獲取快取資源
b：未命中。伺服器會根據請求頭request header驗證這個資源是否命中協商快取，稱之為http二次驗證，命中，伺服器返回請求，但返回資源，而是告訴客戶端直接中直接從瀏覽器快取中獲取
note：
1.強快取不會發生請求，協商快取存在伺服器請求
2.當協商快取也未命中時，則伺服器會將資源傳送到客戶端
3.f5重新整理頁面，會跳過強快取
4.ctrl+f5重新整理頁面，跳過強快取和協商快取
5.不會快取的情況
https post請求 根據cookie獲取認證資訊 request header cache-control：no-cache，max-age=0
6.小故事大道理
上文對整個概念做了闡述，還是不夠形象，我們來通過幾個小故事生動理解一下：
故事一：last-modified
瀏覽器：hi，我需要 jartto.min.js 這個檔案，如果是在 last-modified: fri feb 15 2019 19:57:31 gmt 之後修改過的，請發給我。
伺服器：（檢查檔案的修改時間）
伺服器：oh，這個檔案在那個時間之後沒有被修改過，你已經有最新的版本了。
瀏覽器：太好了，那我就顯示給使用者了。
故事二：etag
瀏覽器：hi，我需要 jartto.css 這個檔案，有沒有不匹配 3c61f-1c1-2aecb436 這個串的
伺服器：（檢查 etag…）
伺服器：hey，我這裡的版本也是 3c61f-1c1-2aecb436，你已經是最新的版本了
瀏覽器：好，那就可以使用本地快取了
看完這兩個小故事，是否對協商快取有了更清晰的認識了。有了，確實很形象
前端快取 瀏覽器快取機制
瀏覽器第一次向伺服器發起該請求後拿到請求結果後,將請求結果和快取標識存入瀏覽器快取,瀏覽器對於快取的處理是根據第一次請求資源時返回的響應頭來確定的。瀏覽器中的快取作用分為兩種情況，一種是需要傳送http請求，一種是不需要傳送。expires 即過期時間 expires max age 請求時間 存在...
瀏覽器快取機制
最近在準備優化日誌請求時遇到了一些令人疑惑的問題，比如為什麼響應頭里出現了兩個 cache control 為什麼明明設定了 no cache 卻還是發請求，為什麼多次訪問時有時請求裡帶了 etag，有時又沒有帶？等等。後來查了一些資料以及同事親自驗證，總算對這些問題有了個清晰的理解，現在整理出來以...
瀏覽器快取機制
當我們瀏覽乙個頁面發現有異常時，通常考慮的就是書不是瀏覽器做了快取呢，按ctrl f5重新請求一次就能請求到沒有快取的頁面，這個是為什麼呢。首先，ctrl f5組合鍵重新整理頁面，那麼瀏覽器會直接向目標url傳送請求，而不再使用瀏覽器快取的資料。其次，當請求到達伺服器端依然有可能出現使用伺服器端的資...