最近對檔案上傳功能進行了優化改版，上線之後有同事反饋出來，自從上線之後所上傳的，均沒有設定瀏覽器端快取，導致客戶端每次都要去請求伺服器上的資源，會導致頁面載入速度變慢，使用者體驗不好諸類問題。之前從未接觸過此類問題趕忙查閱了瀏覽器快取的相關知識，並對問題進行了修復，現將一些所學進行整理歸納。
在chrom瀏覽器中開啟一張，比如華為**p30手機，選擇一張（檢視它的網路請求資訊。
可以理解為無須驗證的快取策略。對強快取來說，響應頭中有兩個字段 expires/cache-control 來表明規則。
expires 指快取過期的時間，超過了這個時間點就代表資源過期。有乙個問題是由於使用具體時間，如果時間表示出錯或者沒有轉換到正確的時區都可能造成快取生命週期出錯。
cache-control 可以由多個字段組合而成，主要有以下幾個取值：
cache-control: max-age =? : 指定乙個時間長度，在這個時間段內快取是有效的，單位是s。例如設定 cache-control:max-age=31536000，也就是說快取有效期為（31536000 / 24 / 60 * 60）天。
cache-control: no-cache強制所有快取了該響應的使用者，在使用已快取的資料前，傳送帶驗證器的請求到伺服器。不是字面意思上的不快取。
cache-control: no-store才是真正的不快取資料到本地
cache-control: public可以被所有使用者快取（多使用者共享），包括終端和cdn等中間**伺服器
cache-control: private只能被終端瀏覽器快取（而且是私有快取），不允許中繼快取伺服器進行快取
快取的資源到期了，並不意味著資源內容發生了改變，如果和伺服器上的資源沒有差異，實際上沒有必要再次請求。客戶端和伺服器端通過某種驗證機制驗證當前請求資源是否可以使用快取。
瀏覽器第一次請求資料之後會將資料和響應頭部的快取標識儲存起來。再次請求時會帶上儲存的頭部字段，伺服器端驗證是否可用。如果返回 304 not modified，代表資源沒有發生改變可以使用快取的資料，獲取新的過期時間。反之返回 200 就相當於重新請求了一遍資源並替換舊資源。
last-modified: 伺服器端資源的最後修改時間，響應頭部會帶上這個標識。第一次請求之後，瀏覽器記錄這個時間，再次請求時，請求頭部帶上 if-modified-since 即為之前記錄下的時間。伺服器端收到帶 if-modified-since 的請求後會去和資源的最後修改時間對比。若修改過就返回最新資源，狀態碼 200，若沒有修改過則返回 304。
由伺服器端上生成的一段 hash 字串，第一次請求時響應頭帶上 etag: abcd，之後的請求中帶上 if-none-match: abcd，伺服器檢查 etag，返回 304 或 200。
客戶端封裝瀏覽器
官網訪問位址 開發時用sdk，開啟的客戶端頁面可以f12檢視頁面資訊 上線時用下面那個。安裝好後的資料夾 vue專案打包，npm run build，生成乙個static資料夾和乙個index.html，index.html就是入口頁面 現在需要建立乙個配置檔案package.json webkit...
有關客戶端瀏覽器快取的Http頭介紹
做 開發離不開快取，快取分好多種 伺服器快取，第三方快取，瀏覽器快取等。其中瀏覽器快取是代價最小的，因為瀏覽器快取依賴的是客戶端，而幾乎不耗費伺服器端的資源。讓瀏覽器做快取需要給瀏覽器傳送指定的http頭，告訴瀏覽器快取多長時間，或者堅決不要快取。作為.net的程式設計師，其實我們一直都在用這種方法...
用於瀏覽器或其他客戶端 WebSocket終成標準
websocket是用於瀏覽器或其他客戶端，建立與web伺服器的雙向 可靠通訊渠道的協議。與其他方法相比的最大好處是，不需要使用多個xml http請求來完成，或者是必須讓乙個正常的http鏈結盡可能長時間的保持open。websocket可以只開啟乙個到伺服器的鏈結，並且在此鏈結上交換資訊。其優勢...