Ⅰ 靜態資源常用的一種緩存方式
http緩存分為強緩存和協商緩存。
強緩存並不會請求伺服器，同時響應碼會返回200。比如使用的配置cache-control:max-age=1200
在項目中緩存圖片等靜態資源常用的是協商緩存。
在第一次請求靜態資源的時候，伺服器會根據資源內容生成etag， 在響應頭里返回給瀏覽器，在下次請求的時候瀏覽器會在頭部配置If-None-Match，攜帶etag來向伺服器詢問資源是否發生改變。若是沒有發生改變會返回304，這樣瀏覽器就不會從伺服器重新獲取資源而是直接使用本地緩存。採用etag可以解決文件名沒有發生變化但是文件內容被修改的問題。
通常會跟cache-control: no-cache 在一起配合使用。no-cache是指瀏覽器可以緩存響應，但是必須要向原始伺服器提交驗證請求。
參考：
https://www.imperva.com/learn/performance/cache-control/
https://blog.csdn.net/aimeimeiTS/article/details/105731709
https://www.zoo.team/article/http-cache
https://imweb.io/topic/5795dcb6fb312541492eda8c
https://aotu.io/notes/2016/09/22/http-caching/index.html
Ⅱ 前端http請求細節——Cache-Control（緩存機制）
請求和響應中的 Cache-Control 指令並不完全相同，具體可以查看 這里 ，包括指令的具體意思，這里不過多贅述。（默認值：private）
瀏覽器的緩存機制是根據 HTTP 報文的緩存標識進行的，瀏覽器第一次向伺服器發起該請求後拿到請求結果，會根據響應報文中 HTTP 頭的緩存標識，決定是否緩存結果。
瀏覽器緩存策略分為兩種：強制緩存和協商緩存。
強制緩存不會向伺服器發送請求，直接從緩存中讀取資源，可以看到請求返回的狀態碼都是200，並且 Size 代表該緩存的位置。
瀏覽器讀取緩存的順序為memory –> disk。
三級緩存原理 (訪問緩存優先順序)：
在瀏覽器中，瀏覽器會在js，字體，圖片等文件解析執行後直接存入內存緩存中，那麼當刷新頁面時只需直接從內存緩存中讀取(from memory cache)；而css文件則會存入硬碟文件中，所以每次渲染頁面都需要從硬碟讀取緩存(from disk cache)。
為什麼CSS會放在硬碟緩存中？
因為CSS文件載入一次就可渲染出來,我們不會頻繁讀取它,所以它不適合緩存到內存中,但是js之類的腳本卻隨時可能會執行,如果腳本在磁碟當中,我們在執行腳本的時候需要從磁碟取到內存中來,這樣IO開銷就很大了,有可能導致瀏覽器失去響應。
若伺服器的資源最後被修改時間 > If-Modified-Since的欄位值
則重新返回資源，狀態碼為200；否則則返回304，代表資源無更新，可繼續使用緩存文件
If-None-Match 的欄位值 = 該資源在伺服器的Etag值
一致則返回304，代表資源無更新，繼續使用緩存文件；不一致則重新返回資源文件，狀態碼為200。
ETag 和 Last-Modified 區別
參考鏈接：
https://juejin.im/entry/5ad86c16f265da505a77dca4
https://www.cnblogs.com/suihang/p/12855345.html
https://www.jianshu.com/p/54cc04190252
Ⅲ 協商緩存和強緩存的區別
協商緩存和強緩存的區別
（1）強緩存
使用強緩存策略時，如果緩存資源有效，則直接使用緩存資源，不必再向伺服器發起請求。
強緩存策略可以通過兩種方式來設置，分別是 http 頭信息中的 Expires 屬性和 Cache-Control 屬性。
（1）伺服器通過在響應頭中添加 Expires 屬性，來指定資源的過期時間。在過期時間以內，該資源可以被緩存使用，不必再向伺服器發送請求。這個時間是一個絕對時間，它是伺服器的時間，因此可能存在這樣的問題，就是客戶端的時間和伺服器端的時間不一致，或者用戶可以對客戶端時間進行修改的情況，這樣就可能會影響緩存命中的結果。
（2）Expires 是 http1.0 中的方式，因為它的一些缺點，在 HTTP 1.1 中提出了一個新的頭部屬性就是 Cache-Control 屬性，它提供了對資源的緩存的更精確的控制。它有很多不同的值，
Cache-Control可設置的欄位：
public：設置了該欄位值的資源表示可以被任何對象（包括：發送請求的客戶端、代理伺服器等等）緩存。這個欄位值不常用，一般還是使用max-age=來精確控制；
private：設置了該欄位值的資源只能被用戶瀏覽器緩存，不允許任何代理伺服器緩存。在實際開發當中，對於一些含有用戶信息的HTML，通常都要設置這個欄位值，避免代理伺服器(CDN)緩存；
no-cache：設置了該欄位需要先和服務端確認返回的資源是否發生了變化，如果資源未發生變化，則直接使用緩存好的資源；
no-store：設置了該欄位表示禁止任何緩存，每次都會向服務端發起新的請求，拉取最新的資源；
max-age=：設置緩存的最大有效期，單位為秒；
s-maxage=：優先順序高於max-age=，僅適用於共享緩存(CDN)，優先順序高於max-age或者Expires頭；
max-stale[=]：設置了該欄位表明客戶端願意接收已經過期的資源，但是不能超過給定的時間限制。
一般來說只需要設置其中一種方式就可以實現強緩存策略，當兩種方式一起使用時，Cache-Control 的優先順序要高於 Expires。
no-cache和no-store很容易混淆：
no-cache 是指先要和伺服器確認是否有資源更新，在進行判斷。也就是說沒有強緩存，但是會有協商緩存；
no-store 是指不使用任何緩存，每次請求都直接從伺服器獲取資源。
（2）協商緩存
如果命中強制緩存，我們無需發起新的請求，直接使用緩存內容，如果沒有命中強制緩存，如果設置了協商緩存，這個時候協商緩存就會發揮作用了。
上面已經說到了，命中協商緩存的條件有兩個：
max-age=xxx 過期了
值為no-store
使用協商緩存策略時，會先向伺服器發送一個請求，如果資源沒有發生修改，則返回一個 304 狀態，讓瀏覽器使用本地的緩存副本。如果資源發生了修改，則返回修改後的資源。
協商緩存也可以通過兩種方式來設置，分別是 http 頭信息中的Etag 和Last-Modified屬性。
（1）伺服器通過在響應頭中添加 Last-Modified 屬性來指出資源最後一次修改的時間，當瀏覽器下一次發起請求時，會在請求頭中添加一個 If-Modified-Since 的屬性，屬性值為上一次資源返回時的 Last-Modified 的值。當請求發送到伺服器後伺服器會通過這個屬性來和資源的最後一次的修改時間來進行比較，以此來判斷資源是否做了修改。如果資源沒有修改，那麼返回 304 狀態，讓客戶端使用本地的緩存。如果資源已經被修改了，則返回修改後的資源。使用這種方法有一個缺點，就是 Last-Modified 標注的最後修改時間只能精確到秒級，如果某些文件在1秒鍾以內，被修改多次的話，那麼文件已將改變了但是 Last-Modified 卻沒有改變，這樣會造成緩存命中的不準確。
（2）因為 Last-Modified 的這種可能發生的不準確性，http 中提供了另外一種方式，那就是 Etag 屬性。伺服器在返回資源的時候，在頭信息中添加了 Etag 屬性，這個屬性是資源生成的唯一標識符，當資源發生改變的時候，這個值也會發生改變。在下一次資源請求時，瀏覽器會在請求頭中添加一個 If-None-Match 屬性，這個屬性的值就是上次返回的資源的 Etag 的值。服務接收到請求後會根據這個值來和資源當前的 Etag 的值來進行比較，以此來判斷資源是否發生改變，是否需要返回資源。通過這種方式，比 Last-Modified 的方式更加精確。
當 Last-Modified 和 Etag 屬性同時出現的時候，Etag 的優先順序更高。使用協商緩存的時候，伺服器需要考慮負載平衡的問題，因此多個伺服器上資源的 Last-Modified 應該保持一致，因為每個伺服器上 Etag 的值都不一樣，因此在考慮負載平衡時，最好不要設置 Etag 屬性。
總結：
強緩存策略和協商緩存策略在緩存命中時都會直接使用本地的緩存副本，區別只在於協商緩存會向伺服器發送一次請求。它們緩存不命中時，都會向伺服器發送請求來獲取資源。在實際的緩存機制中，強緩存策略和協商緩存策略是一起合作使用的。瀏覽器首先會根據請求的信息判斷，強緩存是否命中，如果命中則直接使用資源。如果不命中則根據頭信息向伺服器發起請求，使用協商緩存，如果協商緩存命中的話，則伺服器不返回資源，瀏覽器直接使用本地資源的副本，如果協商緩存不命中，則瀏覽器返回最新的資源給瀏覽器。
Ⅳ ☆前端優化：瀏覽器緩存技術介紹
在前端開發中，性能一直都是被大家所重視的一點，然而判斷一個網站的性能最直觀的就是看網頁打開的速度。 其中提高網頁反應速度的一個方式就是使用緩存 。緩存技術一直一來在WEB技術體系中扮演非常重要角色，是快速且有效地提升性能的手段。
一個優秀的緩存策略可以縮短網頁請求資源的距離，減少延遲，並且由於緩存文件可以重復利用，還可以減少帶寬，降低網路負荷。
所以，緩存技術是無數WEB開發從業人員在工作過程中不可避免的一大問題。 在產品開發的時候我們總是想辦法避免緩存產生，而在產品發布之時又在想策略管理緩存提升網頁的訪問速度 。了解瀏覽器的緩存命中原理，是開發WEB應用的基礎，本文著眼於此，學習瀏覽器緩存的相關知識，總結緩存避免和緩存管理的方法，結合具體的場景說明緩存的相關問題。希望能對有需要的人有所幫助。
在實際WEB開發過程中，緩存技術會涉及到不同層、不同端，比如：用戶層、系統層、代理層、前端、後端、服務端等， 每一層的緩存目標都是一致的，就是盡快返回請求數據、減少延遲 ，但每層使用的技術實現是各有不同，面對不同層、不同端的優劣，選用不同的技術來提升系統響應效率。所以，我們首先看下各層的緩存都有哪些技術，都緩存哪些數據，從整體上，對WEB的緩存技術進行了解，如下圖所示：
本篇文章重點講的就是上面紅色框部分緩存內容。
當瀏覽器請求一個網站的時候，會載入各種各樣的資源，比如：HTML文檔、圖片、CSS和JS等文件。對於一些不經常變的內容，瀏覽器會將他們保存在本地的文件中，下次訪問相同網站的時候，直接載入這些資源，加速訪問。
那麼如何知曉瀏覽器是讀取了緩存還是直接請求伺服器？如下圖網站來做個示例：
第一次打開該網站後，如果再次刷新頁面。會發現瀏覽器載入的眾多資源中，有一部分size有具體數值，然而還有一部分請求，比如圖片、css和js等文件並沒有顯示文件大小，而是顯示了 from dis cache 或者 from memory cache 字樣。這就說明了，該資源直接從本地硬碟或者瀏覽器內存讀取，而並沒有請求伺服器。
瀏覽器啟用緩存至少有兩點顯而易見的好處： （1）減少頁面載入時間；（2）減少伺服器負載；
瀏覽器是否使用緩存、緩存多久，是由伺服器控制的 。准確來說，當瀏覽器請求一個網頁（或者其他資源）時， 伺服器發回的響應的「響應頭」部分的某些欄位指明了有關緩存的關鍵信息 。下面看下，HTTP報文中與緩存相關的首部欄位：
根據上面四種類型的首部欄位不同使用策略， 瀏覽器中緩存可分為強緩存和協商緩存 ：
當瀏覽器對某個資源的請求命中了強緩存時， 返回的HTTP狀態為200 ，在chrome的開發者工具的network裡面 size會顯示為from cache ，比如：京東的首頁里就有很多靜態資源配置了強緩存，用chrome打開幾次，再用f12查看network，可以看到有不少請求就是從緩存中載入的：
Expires是HTTP 1.0提出的一個表示資源過期時間的header，它描述的是一個絕對時間，由伺服器返回，用GMT格式的字元串表示 ，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，包含了Expires頭標簽的文件，就說明瀏覽器對於該文件緩存具有非常大的控制權。
例如，一個文件的Expires值是2020年的1月1日，那麼就代表，在2020年1月1日之前，瀏覽器都可以直接使用該文件的本地緩存文件，而不必去伺服器再次請求該文件，哪怕伺服器文件發生了變化。
所以， Expires是優化中最理想的情況，因為它根本不會產生請求 ，所以後端也就無需考慮查詢快慢。它的緩存原理，如下：
Expires是較老的強緩存管理header， 由於它是伺服器返回的一個絕對時間 ，在伺服器時間與客戶端時間相差較大時，緩存管理容易出現問題， 比如：隨意修改下客戶端時間，就能影響緩存命中的結果 。所以在HTTP 1.1的時候，提出了一個新的header， 就是Cache-Control，這是一個相對時間，在配置緩存的時候，以秒為單位，用數值表示 ，如：Cache-Control:max-age=315360000，它的緩存原理是：
Cache-Control描述的是一個相對時間 ，在進行緩存命中的時候， 都是利用客戶端時間進行判斷 ，所以相比較Expires，Cache-Control的緩存管理更有效，安全一些。
這兩個header可以只啟用一個，也可以同時啟用， 當response header中，Expires和Cache-Control同時存在時，Cache-Control優先順序高於Expires ：
此外，還可以為 Cache-Control 指定 public 或 private 標記。 如果使用 private，則表示該資源僅僅屬於發出請求的最終用戶，這將禁止中間伺服器（如代理伺服器）緩存此類資源 。對於包含用戶個人信息的文件（如一個包含用戶名的 HTML 文檔），可以設置 private，一方面由於這些緩存對其他用戶來說沒有任何意義，另一方面用戶可能不希望相關文件儲存在不受信任的伺服器上。需要指出的是，private 並不會使得緩存更加安全，它同樣會傳給中間伺服器（如果網站對於傳輸的安全性要求很高，應該使用傳輸層安全措施）。 對於 public，則允許所有伺服器緩存該資源 。通常情況下，對於所有人都可以訪問的資源（例如網站的 logo、圖片、腳本等）， Cache-Control 默認設為 public 是合理的 。
當瀏覽器對某個資源的請求沒有命中強緩存， 就會發一個請求到伺服器，驗證協商緩存是否命中，如果協商緩存命中，請求響應返回的http狀態為304並且會顯示一個Not Modified的字元串 ，比如你打開京東的首頁，按f12打開開發者工具，再按f5刷新頁面，查看network，可以看到有不少請求就是命中了協商緩存的：
查看單個請求的Response Header， 也能看到304的狀態碼和Not Modified的字元串，只要看到這個就可說明這個資源是命中了協商緩存，然後從客戶端緩存中載入的 ，而不是伺服器最新的資源：
【Last-Modified，If-Modified-Since】的控制緩存的原理，如下 ：
【Last-Modified，If-Modified-Since】都是根據伺服器時間返回的header，一般來說， 在沒有調整伺服器時間和篡改客戶端緩存的情況下，這兩個header配合起來管理協商緩存是非常可靠的，但是有時候也會伺服器上資源其實有變化，但是最後修改時間卻沒有變化的情況 ，而這種問題又很不容易被定位出來，而當這種情況出現的時候，就會影響協商緩存的可靠性。 所以就有了另外一對header來管理協商緩存，這對header就是【ETag、If-None-Match】 。它們的緩存管理的方式是：
Etag和Last-Modified非常相似，都是用來判斷一個參數，從而決定是否啟用緩存。 但是ETag相對於Last-Modified也有其優勢，可以更加准確的判斷文件內容是否被修改 ，從而在實際操作中實用程度也更高。
協商緩存跟強緩存不一樣，強緩存不發請求到伺服器， 所以有時候資源更新了瀏覽器還不知道，但是協商緩存會發請求到伺服器 ，所以資源是否更新，伺服器肯定知道。大部分web伺服器都默認開啟協商緩存，而且是同時啟用【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】，比如apache:
如果沒有協商緩存，每個到伺服器的請求，就都得返回資源內容，這樣伺服器的性能會極差。
【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】一般都是同時啟用，這是為了處理Last-Modified不可靠的情況。有一種場景需要注意：
比如，京東頁面的資源請求，返回的repsonse header就只有Last-Modified，沒有ETag：
協商緩存需要配合強緩存使用，上面這個截圖中，除了Last-Modified這個header，還有強緩存的相關header， 因為如果不啟用強緩存的話，協商緩存根本沒有意義 。
如果資源已經被瀏覽器緩存下來，在緩存失效之前，再次請求時，默認會先檢查是否命中強緩存，如果強緩存命中則直接讀取緩存，如果強緩存沒有命中則發請求到伺服器檢查是否命中協商緩存，如果協商緩存命中，則告訴瀏覽器還是可以從緩存讀取，否則才從伺服器返回最新的資源。其瀏覽器判斷緩存的詳細流程圖，如下：
Ⅳ 瀏覽器緩存（http緩存）
瀏覽器緩存有兩種：強制緩存和協商緩存
向瀏覽器緩存中查找請求結果，根據【緩存規則】決定是否使用該結果。
強制緩存失效後，攜帶緩存標識請求伺服器，伺服器根據緩存標識判斷是否使用緩存
當瀏覽器向伺服器發送請求的時候，伺服器會將緩存規則放入HTTP響應的報文的HTTP頭中和請求結果一起返回給瀏覽器（ps：下文說的時間點均為類似：Sat Aug 14 2021 11:01:52，秒級）
兩個欄位：Expires和Cache-Control，優先順序：Cache-Control > Expires，客戶端比較時間
Expires ：HTTP/1.0，返回值為【到期時間點】，再次請求，客戶端的時間< Expires，直接用緩存（ps：客戶端與伺服器端時間可能存在誤差，出問題）
Cache-Control ：HTTP/1.1，有以下欄位
Last-Modified / If-Modified-Since 和 Etag / If-None-Match，優先順序Etag > Last-Modified，伺服器比較時間
Last-Modified（服務端返回客戶端） / If-Modified-Since（客戶端傳入服務端） ：兩個值相同，表示：資源文件在伺服器最後被修改的時間【時間點】。
Etag（服務端返回客戶端） / If-None-Match（客戶端傳入服務端） ，兩個值相同，為當前資源文件的一個唯一標識(由伺服器生成)
Etag什麼時候用
雅虎禁用了Etag：因為ETag的值和伺服器有關，那麼對於同樣的文件，可能下次請求的時候是發給不同的伺服器，結果也會重新發送數據，所以就會影響網頁載入速度，增加伺服器的壓力（但Last-Modified也與伺服器有關）
主要解決的問題：
瀏覽器的每個tab都是一個進程
兩個緩存的地方 from memory cache（內存緩存） 和 from disk cache（硬碟緩存） ，讀取順序為memory > disk
Ⅵ 關於html緩存設置
通過HTTP的META設置expires和cache-control
指令不區分大小寫，並且具有可選參數，可以用令牌或者帶引號的字元串語法。多個指令以逗號分隔。
客戶端可以在HTTP請求中使用的標准 Cache-Control 指令。
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: only-if-cached
伺服器可以在響應中使用的標准 Cache-Control 指令。
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: public
Cache-control: private
Cache-control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-control: s-maxage=<seconds>
拓展緩存指令不是HTTP緩存標準的一部分，使用前請注意檢查 兼容性 ！
Cache-control: immutable
Cache-control: stale-while-revalidate=<seconds>
Cache-control: stale-if-error=<seconds>
public
表明響應可以被任何對象（包括：發送請求的客戶端，代理伺服器，等等）緩存。
private
表明響應只能被單個用戶緩存，不能作為共享緩存（即代理伺服器不能緩存它）。
no-cache
強制所有緩存了該響應的緩存用戶，在使用已存儲的緩存數據前，發送帶驗證器的請求到原始伺服器
only-if-cached
表明如果緩存存在，只使用緩存，無論原始伺服器數據是否有更新
max-age=<seconds>
設置緩存存儲的最大周期，超過這個時間緩存被認為過期(單位秒)。與Expires相反，時間是相對於請求的時間。
s-maxage=<seconds>
覆蓋max-age 或者 Expires 頭，但是僅適用於共享緩存(比如各個代理)，並且私有緩存中它被忽略。
max-stale[=<seconds>]
表明客戶端願意接收一個已經過期的資源。 可選的設置一個時間(單位秒)，表示響 應不能超過的過時時間。
min-fresh=<seconds>
表示客戶端希望在指定的時間內獲取最新的響應。
must-revalidate
緩存必須在使用之前驗證舊資源的狀態，並且不可使用過期資源。
proxy-revalidate
與must-revalidate作用相同，但它僅適用於共享緩存（例如代理），並被私有緩存忽略。
immutable
表示響應正文不會隨時間而改變。資源（如果未過期）在伺服器上不發生改變，因此客戶端不應發送重新驗證請求頭（例如If-None-Match或If-Modified-Since）來檢查更新，即使用戶顯式地刷新頁面。在Firefox中，immutable只能被用在 https:// transactions.
發送如下指令可以關閉緩存。此外，可以參考Expires 和 Pragma 標題。
對於應用程序中不會改變的文件，你通常可以在發送響應頭前添加積極緩存。這包括例如由應用程序提供的靜態文件，例如圖像，CSS文件和JavaScript文件。另請參閱Expires標題。
緩存主要兩個策略 強制緩存 ，協商緩存
強制緩存就是設置本地資源html img js等等緩存多長時間 超過時間就去伺服器端取。
協商緩存就是每次都詢問伺服器資源是否已經過期 沒有過期就使用緩存 已經過期就從伺服器上重新取。
緩存流程可以分三個階段 本地緩存，協商緩存 ，緩存失敗
現在的vue項目里都不是這樣緩存的 我個人感覺這是在靜態頁面時的緩存辦法
現在都是webpack打包時通過 hash chunkhash contenthash來決定緩存方式 主要就是在請求的文件名稱後面加一個id 來判斷文件是否已經更新。
Ⅶ 北大青鳥java培訓：什麼是瀏覽器緩存
什麼是瀏覽器緩存瀏覽器緩存(BrowerCaching)是瀏覽器在本地磁碟對用戶最近請求過的文檔進行存儲，當訪問者再次訪問同一頁面時，瀏覽器就可以直接從本地磁碟載入文檔。
瀏覽器緩存的優點有：減少了冗餘的數據傳輸，節省了網費減少了伺服器的負擔，大大提升了網站的性能加快了客戶端載入網頁的速度在前端開發面試中，瀏覽器緩存是web性能優化面試題中很重要的一個知識點，從而說明瀏覽器緩存是提升web性能的一大利器，但是瀏覽器緩存如果使用不當，也會產生很多問題，正所謂是，想說愛你，並不是很容易的事。
所以，結合最近遇到的案例，本文對瀏覽器緩存相關的知識進行總結歸納，希望對讀者有所幫助。
瀏覽器緩存的分類瀏覽器緩存主要有兩類：緩存協商和徹底緩存，也有稱之為協商緩存和強緩存。
瀏覽器在第一次請求發生後，再次請求時：瀏覽器會先獲取該資源緩存的header信息，根據其中的expires和cahe-control判斷是否命中強緩存，若命中則直接從緩存中獲取資源，包括緩存的header信息，本次請求不會與伺服器進行通信;如果沒有命中強緩存，瀏覽器會發送請求到伺服器，該請求會攜帶第一次請求返回的有關緩存的header欄位信息(Last-Modified/IF-Modified-Since、Etag/IF-None-Match),由伺服器根據請求中的相關header信息來對比結果是否命中協商緩存，若命中，則伺服器返回新的響應header信息更新緩存中的對應header信息，但是並不返回資源內容，它會告知瀏覽器可以直接從緩存獲取;否則返回最新的資源內容強緩存強緩存是利用http的返回頭中的Expires或者Cache-Control兩個欄位來控制的，用來表示資源的緩存時間。
Expires該欄位是http1.0時的規范，它的值為一個絕對時間的GMT格式的時間字元串，比如Expires:Mon,18Oct206623:59:59GMT。
這個時間代表著這個資源的失效時間，在此時間之前，山東電腦培訓建議即命中緩存。
這種方式有一個明顯的缺點，由於失效時間是一個絕對時間，所以當伺服器與客戶端時間偏差較大時，就會導致緩存混亂。
Ⅷ http緩存之基本概念
1. 重要性
綜上所述，所以大家很有必要花時間來研究。
2. 困難之處
個人認為http緩存是比較枯燥的理論知識，尤其對於前端來講，更多在於理解概念，以及內部緩存機制，而沒有什麼實踐可以鞏固，或者說理論和現實脫軌。
瀏覽器會在請求資源之後，根據自己的緩存策略判斷是否對資源進行緩存，當再次請求相同的資源時，瀏覽器根據緩存策略判斷是通過本地緩存獲取資源，還是重新向伺服器發起請求。
這個 緩存策略 到底是什麼呢？
實際每個瀏覽器的緩存策略是有差異的，但大致受以下幾個因素的影響。
搜索關鍵字 禁止 html 緩存 ，很容易搜到以下答案：
但是，這是 Html 4.0 中的規范，在 Html 5.0 的規范中 http-equiv 已經不存在以上屬性值了。
而且代理伺服器並不會讀取以上meta標簽，不利於代理伺服器的緩存。
-- 引用自 stackoverflow
綜上所述， html meta 是一個不那麼可靠，並且已經過時的解決方案，所以不建議再繼續使用 。
基於 HTTP 協議的緩存策略，分為 強緩存 和 協商緩存 , 由 HTTP 協議的首部 (Headers) 信息決定。具體的操作設置需要伺服器配合，比如 Nginx 。所以相對來說都是後端在做此類事情，前端接觸的機會比較少。
如果開啟了強緩存，並且在過期時間之內，則瀏覽器不再發起請求，直接使用本地的緩存資源。
Expires 和 Cache-control 用於控制強制緩存。
Expires 是 HTTP 1.0 的特性。通過指定一個明確的時間點作為緩存資源的過期時間，客戶端會根據此時間點來判斷到底使用本地緩存，還是向伺服器重新請求資源。
優點： 在緩存過期時間內，減少客戶端的 HTTP 請求，不僅節省了客戶端處理時間，提高了 web 應用的執行速度，而且減少了伺服器負載，以及客戶端網路資源的消耗。
缺點：指定的過期時間以伺服器為准，但是客戶端進行過期時間判斷時是將 本地的時間 與 指定的過期時間點 進行對比。如果客戶端修改了本地時間，將會影響對緩存的判斷。
Cache-control 是HTTP1.1 新增的特性，以便更精準地控制緩存。此首部信息 具有最高的優先順序。
max-age 指定的是緩存的時間跨度，而非緩存失效的時間點。優先順序比 Expires 高。
如果需要使用協商緩存，需要 將 Cache-control 指定為 no-cache 或者 max-age 、Expires 均過期之後。
協商緩存：瀏覽器本地是有緩存的，但是要先發起請求，由伺服器判斷緩存是否過期。
Last-Modified / If-Modified-Since
last-Modified 是 HTTP 1.0 的特性，是伺服器端在響應請求時用來說明資源的最後修改時間。
缺點：
Etag / If-None-Match
Etag 是 HTTP 1.1 的特性，是伺服器為資源分配的字元串形式唯一性標識，作為響應首部返回給瀏覽器。
採用弱比較，內容沒變化，時間變化了，會認為是資源未變化。
瀏覽器之HTTP緩存的那些事
304和瀏覽器http緩存
瀏覽器緩存機制剖析
瀏覽器緩存機制介紹
技術研究 vue項目的性能優化之路
HTTP緩存控制小結
Ⅸ 瀏覽器緩存的方式和類型（筆記）
瀏覽器緩存只是計算機緩存的一種
1.內存緩存
將數據存到內存
2.代理伺服器緩存
就是個自己找的中介。你拿東西先找中介，中介找房東，房東給中介，中介又給你。比如你需要房子鑰匙，房東把鑰匙放在中介那，你直接從中介那裡拿鑰匙。
3.CDN緩存
將數據存到CDN伺服器。CDN也是個中介，不過這個中介是根據中介的忙碌程度（CDN伺服器忙碌程度）、跟你的距離（CDN伺服器和你的距離）自動給你分配的。
4.瀏覽器緩存（ 我是個前端，只關注瀏覽器緩存。 ）
根據HTTP協議決定要不要緩存，以什麼方式緩存，緩存到哪（內存還是硬碟等）。
瀏覽器緩存是將瀏覽器請求過的數據（資源文件）保存到電腦上。需要再次使用的時候，直接從電腦上獲取保存的數據（資源文件），這就是瀏覽器緩存
1.減少網路請求，節省流量
2.減輕伺服器壓力
3.資源載入速度快了，前端性能就更好了
1.Server Worker
還沒搞懂，搞懂了再來寫。
2.Memory Cache
內存中的緩存，關閉頁面進程就釋放內存
3.Disk Memory
硬碟中的緩存，不主動清理就一直在
4、Push Cache
推送緩存，是HTTP/2的內容，並沒有嚴格執行HTTP頭部的緩存指令。在Server Worker、Memory Cache、Disk Cache都沒有命中的時候，它會被使用。在Session中存在，Session結束就會被釋放，緩存時間短暫。
1.先去內存查找，找到直接載入
2.內存找不到，硬碟中找，找到直接載入
3.硬碟找不到進行網路請求
4.把請求獲取的資源再緩存到硬碟和內存
1.強緩存
控制強制緩存的欄位分別是Expires和Cache-Control，Cache-Control優先順序比Expires高
-Expires設置一個絕對時間的GMT格式的時間字元串，這個是資源失效時間（ 客戶端的時間小於Expires的值，缺陷就是客戶端的時間被改變就有問題 ），在這個時間之前都直接讀取緩存。
-Cache-Control替代Expires，它利用的是相對時間，利用header信息欄位的max-age值判斷。
2.協商緩存
-Last-Modified/If-Modified-Since
Last-Modified:瀏覽器向伺服器發送資源最後的修改時間
If-Modified-Since:當資源過期時，發現響應頭具有Last-Modified聲明，則再次向伺服器請求時帶上頭if-modified-since，表示請求時間。伺服器收到請求後，發現有if-modified-since則與被請求資源的最後修改時間進行對比（Last-Modified）,若最後修改時間較新，說明資源又被改過，則返回最新資源，返回200；若最後修改時間較小，說明資源無新修改，返回304 ，使用緩存文件。
缺點:單位是秒，一秒內多次改變會認為沒過期
-ETag/If-None-Match
ETag:由伺服器生成返回給前端，幫助伺服器控制web端的緩存驗證，伺服器會生成並且返回當前資源文件的一個唯一標識
If-None-Match:當資源過期時，發現響應頭具有Etag聲明，則再次向伺服器請求時帶上頭if-none-match（唯一標識Etag值）。伺服器收到該請求後，發現有If-None-Match則根據If-None-Match的欄位值與該資源在伺服器的Etag值做對比，一致則返回304，代表資源無更新，繼續使用緩存文件；不一致則重新返回資源文件，狀態碼為200。
1.強緩存不發請求，協商緩存會發請求給伺服器確認有沒有過期
2.強緩存文件更新瀏覽器不知道，協商緩存更新瀏覽器能實時知道
1.點擊瀏覽器的刷新按鈕時，全部走緩存
2.F5或者滑鼠右鍵刷新強制緩存失效，不影響協商緩存
3.CTRL+F5影響強制緩存和協商緩存都失效
Ⅹ 前端瀏覽器緩存機制
在前端開發中，性能是一個永恆的話題，沒有最好，只有更好。判斷一個網站性能好壞，一個直入眼觀的即是網頁的反應速度，有一個方式就是使用緩存，一個優秀的緩存策略可以縮短網頁請求的時間，減少延遲，並且網頁可以重復利用，還可以減少帶寬，降低網路負荷。
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，你已經是最新的版本了
瀏覽器：好，那就可以使用本地緩存了