說真的，當自己還很小白的時候，明明修改了js的內容了，但是就是沒有載入成功，那時候感覺好神奇，好沒道理。後來知道了這是因為快取的原因。
說實話，現在基於各種框架的開發，基本上沒有在業務**過程中關注快取的事情了，當然，不包括使用localstorage和cookie。今天自己學習了一些關於前端快取的東西，不一定有什麼特別的用，僅讓自己知道快取，說不定哪天就用上了。
前端分為http快取和瀏覽器快取。http快取幾乎沒用過，也不知道有沒有不經意間使用了，因為http快取主要是伺服器**上設定的。
http第一次請求之後，伺服器會在返回的頭部傳回快取的引數。然後第二次請求的時候瀏覽器判斷這些引數是什麼快取型別，相應的返回。
http快取有強快取和協商快取（也有人叫對比快取）。
強快取：
http狀態碼是200，f5重新整理和ctrl+f5重新整理無效，強快取一般用到兩個key:
expires:快取過期時間，再次發起請求之後，瀏覽器會先判斷是否在有效期之內，如果是就直接使用本地快取，不會去請求。有乙個缺點就是，有效期是伺服器給的，不排除本地時間跟伺服器有誤差，本人認為這個誤差可以忽略不計。
cache-control，優先順序比expires高：有五個引數：
no-cache:快取了資料，但是請求的時候直接繞過快取向伺服器請求，有些瀏覽器無效；
no-store：不儲存快取，比no-cache更粗暴；
max-age：設定時效，在有效時間內直接使用，不去請求。
public：客戶端和服務端都能快取；
private：客戶端可以快取；
強快取其實是比較推薦的，因為不會發起請求，那麼應該有人會問，如果強快取了，那麼修改了怎麼讓客戶端更新。其實很簡單，給檔案加hash值就會請求修改過的檔案。
對比快取（協商快取）：http狀態碼是304，是由伺服器決定的，f5重新整理有效，ctrl+f5重新整理無效，對比快取的key是成對出現的：
last-modify/if-modify-since: 響應端先返回乙個last-modified時間，再次請求的時候 request頭部會將快取中的last-modified欄位拿出來賦給if-modified-since，傳送給伺服器，伺服器去判斷時間是否過期，如未過期則返回304，告訴客戶使用快取資料，如果過期則重新返回乙個last-modified並且返回200；
etag/if-none-match: 根據實體內容生成的一段hash字串，可以標識資源的狀態。 當資源傳送改變時，etag也隨之發生變化。主要是為了解決根據時間無法解決的問題：比如檔案修改頻繁，導致根據時間無法判斷是否更新等。
說了這麼多，http快取跟前端有什麼關係？確實，大部分http快取是由伺服器完成，關於前端怎麼操作的沒查到相關的文件，只知道可以通過meta標籤禁用快取和動態設定header。
快取對於前端的效能優化算是很大的，推薦使用強快取，然後用hash值的方法消除強快取的影響。
如果有人知道前端怎麼去操作http快取，希望可以指教一下。
前端快取之HTTP快取（二）
http快取 當客戶端向服務端請求資源時，會先去到瀏覽器快取，如果瀏覽器快取有需要請求資源的副本，就可以直接從瀏覽器快取中提取，而不會去到伺服器。常見的http快取都只能快取get方式請求響應的資源，不能處理其他型別的響應。http快取都是從第二次請求開始的，當第一次請求資源時，伺服器會返回資源，並...
前端快取總結 HTTP快取
在前端面試中，可能或多或少都會被提及快取問題，而這個問題大多數都是作為業務中不得不考慮的乙個效能優化點，如果平時沒有怎麼關注或是特意去了解這塊的童鞋們，可能就是不太了解其中的原由，那麼今天我們就這個快取問題來細細分析，幫助一些還不是太明白的或是剛入門的前端童鞋們梳理梳理，理解理解，那就話不多說，開始...
前端http快取
協商快取 禁用快取 指的是瀏覽器第一次請求資源時，瀏覽器快取在本地，並設定時間，如果在這個時間內再次請求，便會讀取快取的資源。對應策略為expires 和 cache control，cache control的優先順序高於expires。強制快取不會請求伺服器。expires 我們用pragma來...