一、
http1.1無效 現都是http1.0的天下了
以上三種基本可以忽略，因為大多情況下都是無效的。
無法被瀏覽器快取的請求：
http資訊頭中包含cache-control:no-cache，pragma:no-cache（http1.0），或cache-control:max-age=0等告訴瀏覽器不用快取的請求（無效）
需要根據cookie，認證資訊等決定輸入內容的動態請求是不能被快取的
經過https安全加密的請求（有人也經過測試發現，ie其實在頭部加入cache-control：max-age資訊，firefox在頭部加入cache-control:public之後，能夠對https的資源進行快取）
post請求無法被快取
http響應頭中不包含last-modified/etag，也不包含cache-control/expires的請求無法被快取
二、下面的是瀏覽器讀取檔案的整個流程，很全很強大
四、 瀏覽器快取機制的詳細說明
另外，cache-control 與 last-modified 是瀏覽器核心的機制，一般都是標準的實現，不能更改或設定。以 qq 瀏覽器的 x5為例，cache-control 與 last-modified 快取不能禁用。快取容量是12mb，不分host，過期的快取會最先被清除。如果都沒過期，應該優先清最早的快取或最快到期的或檔案大小最大的；過期快取也有可能還是有效的，清除快取會導致資源檔案的重新拉取。
還有，瀏覽器，如 x5，在使用快取檔案時，是沒有對快取檔案內容進行校驗的，這樣快取檔案內容被修改的可能。
分析發現，瀏覽器的快取機制還不是非常完美的快取機制。完美的快取機制應該是這樣的：
快取檔案沒更新，盡可能使用快取，不用和伺服器互動；
快取檔案有更新時，第一時間能使用到新的檔案；
快取的檔案要保持完整性，不使用被修改過的快取檔案；
快取的容量大小要能設定或控制，快取檔案不能因為儲存空間限制或過期被清除。
以x5為例，第1、2條不能同時滿足，第3、4條都不能滿足。
在實際應用中，為了解決 cache-control 快取時長不好設定的問題，以及為了」消滅304「，web前端採用的方式是：
在要快取的資源檔名中加上版本號或檔案 md5值字串，如 common.d5d02a02.js，common.v1.js，同時設定 cache-control:max-age=31536000，也就是一年。在一年時間內，資源檔案如果本地有快取，就會使用快取；也就不會有304的回包。
如果資源檔案有修改，則更新檔案內容，同時修改資源檔名，如 common.v2.js，html頁面也會引用新的資源檔名。
通過這種方式，實現了：快取檔案沒有更新，則使用快取；快取檔案有更新，則第一時間使用最新檔案的目的。即上面說的第1、2條。第3、4條由於瀏覽器內部機制，目前還無法滿足。
dom storage 儲存機制
dom storage 是通過儲存字串的 key/value 對來提供的，並提供 5mb （不同瀏覽器可能不同，分 host)的儲存空間（cookies 才 4kb)。另外 dom storage 儲存的資料在本地，不像 cookies，每次請求一次頁面，cookies 都會傳送給伺服器。
dom storage 分為 sessionstorage 和 localstorage。localstorage 物件和 sessionstorage 物件使用方法基本相同，它們的區別在於作用的範圍不同。sessionstorage 用來儲存與頁面相關的資料，它在頁面關閉後無法使用。而 localstorage 則持久存在，在頁面關閉後也可以使用。
瀏覽器快取機制
最近在準備優化日誌請求時遇到了一些令人疑惑的問題，比如為什麼響應頭里出現了兩個 cache control 為什麼明明設定了 no cache 卻還是發請求，為什麼多次訪問時有時請求裡帶了 etag，有時又沒有帶？等等。後來查了一些資料以及同事親自驗證，總算對這些問題有了個清晰的理解，現在整理出來以...
瀏覽器快取機制
當我們瀏覽乙個頁面發現有異常時，通常考慮的就是書不是瀏覽器做了快取呢，按ctrl f5重新請求一次就能請求到沒有快取的頁面，這個是為什麼呢。首先，ctrl f5組合鍵重新整理頁面，那麼瀏覽器會直接向目標url傳送請求，而不再使用瀏覽器快取的資料。其次，當請求到達伺服器端依然有可能出現使用伺服器端的資...
瀏覽器快取機制
瀏覽器快取機制 瀏覽器快取機制，其實主要就是 協議定義的快取機制 如 expires cache control 等 但是也有非 協議定義的快取機制，如使用 html meta 標籤，web 開發者可以在 html 頁面的節點中加入 標籤，如下 上述 的作用是告訴瀏覽器當前頁面不被快取，每次訪問都需...