很早就想梳理一下瀏覽器的緩存機制了，一直沒有時間，實際是上懶啦(*^▽^*)，你知道的，人都有惰性，本大神只是個假神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，你已經是最新的版本了
瀏覽器：好，那就可以使用本地緩存了
看完這兩個小故事，是否對協商緩存有了更清晰的認識了。有了，確實很形象
參考鏈接：
https://www.toutiao.com/i6719737927439483400/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1×tamp=1568456352&app=news_article&utm_source=weixin&utm_medium=toutiao_ios&req_id=201909141819110100140470141C9477FF&group_id=6719737927439483400