說起快取可謂是讓程式員愛恨交加！我結合專案經驗談談自己的一些見解，
在我們更新完已上線的專案后，用戶瀏覽器顯示的確實舊版的頁面，沒有及時獲取到我們更新的資源，此時用戶重繪一下頁面，就得到了更新后的資源，又是為什么呢？
答案就是瀏覽器快取
瀏覽器快取是前端優化的一個重要問題，快取可以帶來很多好處：
（1）減少冗余的資料傳輸，節省寬帶；
（2）減輕服務器的請求負擔，有快取就可以少向服務器發送請求，尤其是對于一些訪問量很大的網站
（3）資源從快取中讀取，無需向服務器發送請求再等待回傳，加快了客戶端訪問速度
但是快取也同樣給前端帶來了一個很嚴重的問題，就是上面所說的專案更新的問題，如果專案更新了，用戶瀏覽器讀取的是快取資源，雖說重繪或者清除瀏覽器快取可以獲取最新的頁面，但是做開發常說的一句話叫做：要把用戶當傻瓜一樣對待，能少一步絕不多一步（冒犯了冒犯了，立馬道歉）
瀏覽器快取主要指http快取，其機制是根據http報文的快取標識進行相應操作，
瀏覽器有三級快取原理
1.先查找記憶體，如果記憶體中存在，從記憶體中加載；
2.如果記憶體中未查找到，選擇從硬碟獲取，如果硬碟有，從硬碟加載；
3.如果硬碟中未查找到，那就進行網路請求，加載到的資源快取到硬碟和記憶體；
如上常見情況就是我們打開控制臺的Network發現資源加載情況是200 from disk cache，這很明顯瀏覽器沒有請求新的資源，那么有沒有辦法去解決這種情況？
瀏覽器快取（強制快取和、協商快取也叫對比快取）
1.強制快取
見字明意，強制快取就是用戶第一次訪問頁面之后，瀏覽器將資料存在快取之中，在過期時間之內，都不會請求服務器，是否使用強制快取存在于資源是否過期，該過期時間從第一次請求服務器回應頭中獲取，如果在過期時間內，從快取中讀取，如果超出過期時間，則使用協商快取
控制強制快取的欄位分別是Expires和Cache-Control,其中Cache-Control優先級比Expires高，
2.協商快取
從字面上意思主在協商，在第一次請求服務器時，服務器會回傳一個資源的快取標識，一起存到瀏覽器的快取資料庫，第二次請求資源時，瀏覽器會首先將快取標識發送給服務器，服務器處理標識是否匹配，如果不匹配表示資源有更新，服務器會將新資料和快取標識一起回傳瀏覽器；如果匹配，表示資源沒有更新并且回傳304狀態碼，瀏覽器讀取本地快取服務器中的資料
與協商快取相關的欄位是 Last-Modified/If-Modified-Since、Etag/IF-None-Match
Last-Modified與ETag是可以一起使用的，服務器會優先驗證ETag，一致的情況下，才會繼續比對Last-Modified，最后才決定是否回傳304
| 快取型別 | 獲取資源形式 | 狀態碼 | 發送請求到服務器 |
|---|---|---|---|
| 強快取 | 從快取取 | 200（from cache） | 否，直接從快取取 |
| 協商快取 | 從快取取 | 304（Not Modified） | 否，通過服務器來告知快取是否可用 |
| 用戶操作 | Expires/Cache-Control | Last-Modied/Etag | |
|---|---|---|---|
| 地址欄回車 | 有效 | 有效 | |
| 頁面鏈接跳轉 | 有效 | 有效 | |
| 新開視窗 | 有效 | 有效 | |
| 前進回退 | 有效 | 有效 | |
| F5重繪 | 無效 | 有效 | |
| Ctrl+F5強制重繪 | 無效 | 無效 | |
如文章開頭所屬，代碼更新到線上后用戶瀏覽器不能自行更新，我們不能要求客戶在系統更新后都進行一次快取清理的操作， 到底該如何解決呢？ 在資源請求的URL中增加一個引數，比如：js/mian.js?ver=0.7.1，這個引數是一個版本號，每一次部署的時候變更一下，當這個引數變化的時候，強快取都會失效并重新加載
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/317908.html
標籤：java
下一篇：IO流的基本原理和使用