一 瀏覽器緩存機(jī)制

瀏覽器在每次發(fā)生請(qǐng)求時(shí)，先在在瀏覽器緩存中查找該請(qǐng)求的結(jié)果和緩存標(biāo)識(shí)，并且每次收到請(qǐng)求結(jié)果均會(huì)把請(qǐng)求結(jié)果和緩存標(biāo)識(shí)保存在瀏覽器緩存中。
總體腦圖：文中腦圖及流程圖資源

瀏覽器緩存策略分類

緩存策略的分類：

• 強(qiáng)緩存：不會(huì)向服務(wù)器發(fā)送請(qǐng)求，直接從緩存中讀取資源。
• 協(xié)商緩存：強(qiáng)制緩存失效后，瀏覽器攜帶緩存標(biāo)識(shí)向服務(wù)器發(fā)起請(qǐng)求，由服務(wù)器根據(jù)緩存標(biāo)識(shí)決定是否使用緩存的過程

緩存策略通過設(shè)置HTTP Header來實(shí)現(xiàn)的。

-獲取資源形式狀態(tài)碼發(fā)送請(qǐng)求到服務(wù)器相關(guān)設(shè)置字段

強(qiáng)緩存	從緩存取	200（from cache）	否，直接從緩存取	expires，cache-control。如果cache-control與expires同時(shí)存在的話，cache-control的優(yōu)先級(jí)高于expires
協(xié)商緩存	從緩存取	304（not modified）	是，通過服務(wù)器來告知緩存是否可用	Last-Modified/If-Modified-Since，Etag/If-None-Match

瀏覽器緩存的基本流程：

瀏覽器發(fā)送http請(qǐng)求前，先訪問瀏覽器緩存，有緩存則進(jìn)行下一步，否則，進(jìn)行第5步；

在瀏覽器緩存中查找該請(qǐng)求的結(jié)果以及緩存標(biāo)識(shí)： 若請(qǐng)求頭包含expires和cache-control，則為強(qiáng)緩存策略：根據(jù)根據(jù)cache-contrle:max-age=xxxx(優(yōu)先)、expires計(jì)算緩存時(shí)間，若未超時(shí)，則進(jìn)行第4步，若超時(shí)則強(qiáng)制緩存實(shí)效，進(jìn)行下一步；

瀏覽器會(huì)發(fā)送請(qǐng)求，若請(qǐng)求頭未包含的etag、last-modified，則進(jìn)行第5步；否則判斷為協(xié)商緩存，執(zhí)行協(xié)商流程判定：
1). 瀏覽器首次獲取某個(gè)資源的時(shí)候，服務(wù)器會(huì)在返回資源的同時(shí)在響應(yīng)頭部加上Etag(資源的唯一標(biāo)識(shí)字符串)、Last-Modified（資源最后一次在服務(wù)器上被修改的時(shí)間）；
2). 當(dāng)瀏覽器再次請(qǐng)求該資源的時(shí)候，會(huì)在請(qǐng)求頭加上If-None-Match字段（值為1)中Etag值）、If-Modified-Since（值為1)中Last-Modified值）
3). 服務(wù)器收到傳過來的值，再次生成該資源得Etag，并判定Etag與If-None-Match、該資源服務(wù)器上的最后修改時(shí)間與If-Modified-Since是否相等，如果相同，則滿足協(xié)商緩存進(jìn)行第5步。
4). 如果不滿足協(xié)商緩存，則進(jìn)行第6步，更新資源并更新Etag的值、Last-Modified的值。

從緩存讀取，進(jìn)行第7步；

向web服務(wù)器發(fā)送請(qǐng)求，進(jìn)行下一步；

請(qǐng)求響應(yīng)，緩存協(xié)商，進(jìn)行下一步；

數(shù)據(jù)展示

流程圖：

二 瀏覽器緩存策略

1 強(qiáng)緩存

強(qiáng)緩存：不會(huì)向服務(wù)器發(fā)送請(qǐng)求，直接從緩存中讀取資源，在chrome控制臺(tái)的Network選項(xiàng)中可以看到該請(qǐng)求返回200的狀態(tài)碼，并且Size顯示from disk cache或from memory cache。

強(qiáng)緩存可以通過設(shè)置兩種HTTP Header實(shí)現(xiàn)：Expires和Cache-Control。

Expires

Expires是HTTP1.0規(guī)范的產(chǎn)物：

• 值：是服務(wù)器端的具體的時(shí)間點(diǎn)；

• 格式：絕對(duì)時(shí)間的GMT格式的時(shí)間字符串：Expires: Wed, 22 Oct 2021 18:41:00 GMT 表示資源會(huì)在Wed, 22 Oct 2021 18:41:00 GMT后過期，需要再次請(qǐng)求。

• Expires控制緩存的原理：使用客戶端的時(shí)間與服務(wù)端返回的時(shí)間做對(duì)比，如果客戶端與服務(wù)端的時(shí)間由于某些原因（時(shí)區(qū)不同、客戶端和服務(wù)端有一方的時(shí)間不準(zhǔn)確）發(fā)生誤差，那么強(qiáng)制緩存直接失效，那么強(qiáng)制緩存存在的意義就毫無意義。

• 到了HTTP/1.1，Expires已經(jīng)被Cache-Control替代，且現(xiàn)在瀏覽器的默認(rèn)使用的是HTTP/1.1

  網(wǎng)頁(yè)的response headers部分如下：優(yōu)先考慮max-age，則示資源可以被緩存的最長(zhǎng)時(shí)間為691200秒

  cache-control:max-age=691200 expires: Wed, 22 Oct 2021 18:41:00 GMT

Cache-Control

在HTTP/1.1中，Cache-Control是最重要的規(guī)則，主要用于控制網(wǎng)頁(yè)緩存。

• 值：一個(gè)相對(duì)時(shí)間。比如當(dāng)Cache-Control:max-age=300時(shí)，則代表在這個(gè)請(qǐng)求正確返回時(shí)間（瀏覽器也會(huì)記錄下來）的300s內(nèi)再次加載資源，就會(huì)命中強(qiáng)緩存，直接從緩存中獲取資源；
• 格式：數(shù)字，單位s；
• Cache-Control控制緩存的原理： 超時(shí)時(shí)間截點(diǎn) = 資源返回時(shí)間+ Cache-Control的相對(duì)時(shí)間。
• Cache-Control可以在請(qǐng)求頭或者響應(yīng)頭中設(shè)置，并且可以組合使用多種指令：

指令作用

public	表示響應(yīng)可以被客戶端和CDN等代理服務(wù)器緩存
private	表示響應(yīng)只可以被客戶端緩存，Cache-Control的默認(rèn)取值
max-age=30	緩存30s后就過期，需要重新請(qǐng)求
s-maxage=30	優(yōu)先級(jí)高于max-age，存在時(shí)會(huì)覆蓋max-age，作用一樣，只在代理服務(wù)器中生效，ax-age用于普通緩存，而s-maxage用于代理緩存。
no-store	不緩存任何響應(yīng)，即不使用強(qiáng)制緩存，也不使用協(xié)商緩存
no-cache	資源被客戶端緩存，是否使用緩存則需要經(jīng)過協(xié)商緩存來驗(yàn)證決定。表示不使用 Cache-Control的緩存控制方式做前置驗(yàn)證，而是使用 Etag 或者Last-Modified字段來控制緩存。
max-stale=30	能容忍的最大過期時(shí)間。30s秒內(nèi)，即使緩存過期，也使用該緩存
min-fresh=30	能夠容忍的最小新鮮度。希望在30s內(nèi)獲取最新的響應(yīng)

Expires和Cache-Control兩者對(duì)比: Cache-Control優(yōu)先級(jí)高于Expires；在某些不支持HTTP1.1的環(huán)境下，Expires就會(huì)發(fā)揮用處。

強(qiáng)緩存判斷是否緩存的依據(jù)來自于是否超出某個(gè)時(shí)間或者某個(gè)時(shí)間段，而不關(guān)心服務(wù)器端文件是否已經(jīng)更新，這可能會(huì)導(dǎo)致加載文件不是服務(wù)器端最新的內(nèi)容，那我們?nèi)绾潍@知服務(wù)器端內(nèi)容是否已經(jīng)發(fā)生了更新呢？此時(shí)我們需要用到協(xié)商緩存策略。

2 協(xié)商緩存

協(xié)商緩存就是強(qiáng)制緩存失效后，瀏覽器攜帶緩存標(biāo)識(shí)向服務(wù)器發(fā)起請(qǐng)求，由服務(wù)器根據(jù)緩存標(biāo)識(shí)決定是否使用緩存的過程，主要有以下兩種情況：

• 協(xié)商緩存生效，返回304和Not Modified
• 協(xié)商緩存失效，返回200和請(qǐng)求結(jié)果
  

協(xié)商緩存的標(biāo)識(shí)也是在響應(yīng)報(bào)文的HTTP頭中和請(qǐng)求結(jié)果一起返回給瀏覽器的，控制協(xié)商緩存的字段分別有：Last-Modified / If-Modified-Since和Etag / If-None-Match，其中Etag / If-None-Match的優(yōu)先級(jí)比Last-Modified / If-Modified-Since高。

Last-Modified和If-Modified-Since

• Last-Modified是服務(wù)器響應(yīng)請(qǐng)求時(shí)，返回該資源文件在服務(wù)器最后被修改的時(shí)間。瀏覽器在第一次訪問資源時(shí)，在response header中添加Last-Modified到header，瀏覽器接收后緩存文件和 header；Last-Modified: Fri, 22 Jul 2021 01:47:00 GMT
• If-Modified-Since則是客戶端再次發(fā)起該請(qǐng)求時(shí)，攜帶上次請(qǐng)求返回的Last-Modified值，通過此字段值告訴服務(wù)器該資源上次請(qǐng)求返回的最后被修改時(shí)間。服務(wù)器收到該請(qǐng)求，發(fā)現(xiàn)請(qǐng)求頭含有If-Modified-Since字段，則會(huì)對(duì)比If-Modified-Since的字段值與該資源在服務(wù)器的最后被修改時(shí)間，若服務(wù)器的資源最后被修改時(shí)間大于If-Modified-Since的字段值，則重新返回資源，狀態(tài)碼為200；否則則返回304，代表資源無更新，可繼續(xù)使用緩存文件，If-Modified-Since: Fri, 21 Jul 2021 01:47:00 GMT

但是 Last-Modified 存在一些弊端：

• 如果本地打開緩存文件，即使沒有對(duì)文件進(jìn)行修改，但還是會(huì)造成Last-Modified被修改，服務(wù)端不能命中緩存導(dǎo)致發(fā)送相同的資源
• 因?yàn)?Last-Modified 只能以秒計(jì)時(shí)，如果在不可感知的時(shí)間內(nèi)修改完成文件，那么服務(wù)端會(huì)認(rèn)為資源還是命中了，不會(huì)返回正確的資源

既然根據(jù)文件修改時(shí)間來決定是否緩存尚有不足，能否可以直接根據(jù)文件內(nèi)容是否修改來決定緩存策略？所以在 HTTP / 1.1 出現(xiàn)了 ETag 和 If-None-Match

ETag和If-None-Match

• Etag是服務(wù)器響應(yīng)請(qǐng)求時(shí)，返回當(dāng)前資源文件的一個(gè)唯一標(biāo)識(shí)(由服務(wù)器生成)，只要資源有變化，Etag就會(huì)重新生成。etag: W/"4d24eb245e63692a52bd1ef1a26b09ad079eacd16becfff8e655bb1b809b98f8"
• If-None-Match是客戶端再次發(fā)起該請(qǐng)求時(shí)，攜帶上次請(qǐng)求返回的唯一標(biāo)識(shí)Etag值，通過此字段值告訴服務(wù)器該資源上次請(qǐng)求返回的唯一標(biāo)識(shí)值。服務(wù)器收到該請(qǐng)求后，發(fā)現(xiàn)該請(qǐng)求頭中含有If-None-Match，則會(huì)根據(jù)If-None-Match的字段值與該資源在服務(wù)器的Etag值做對(duì)比，一致則返回304，代表資源無更新，繼續(xù)使用緩存文件；不一致則重新返回資源文件，狀態(tài)碼為200，如下。if-none-match: W/"4d24eb245e63692a52bd1ef1a26b09ad079eacd16becfff8e655bb1b809b98f8"

兩者之間對(duì)比：

• 首先在精確度上，Etag要優(yōu)于Last-Modified。
  Last-Modified的時(shí)間單位是秒，如果某個(gè)文件在1秒內(nèi)改變了多次，那么他們的Last-Modified其實(shí)并沒有體 現(xiàn)出來修改，但是Etag每次都會(huì)改變確保了精度；如果是負(fù)載均衡的服務(wù)器，各個(gè)服務(wù)器生成的Last- Modified也有可能不一致。

• 第二在性能上，Etag要遜于Last-Modified，畢竟Last-Modified只需要記錄時(shí)間，而Etag需要服務(wù)器通過算法來計(jì)算出一個(gè)hash值。

• 第三在優(yōu)先級(jí)上，服務(wù)器校驗(yàn)優(yōu)先考慮Etag

3 緩存機(jī)制

強(qiáng)制緩存優(yōu)先于協(xié)商緩存進(jìn)行，若強(qiáng)制緩存(Expires和Cache-Control)生效則直接使用緩存，若不生效則進(jìn)行協(xié)商緩存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，協(xié)商緩存由服務(wù)器決定是否使用緩存，若協(xié)商緩存失效，那么代表該請(qǐng)求的緩存失效，返回200，重新返回資源和緩存標(biāo)識(shí)，再存入瀏覽器緩存中；生效則返回304，繼續(xù)使用緩存。

三、緩存位置

清楚了瀏覽器緩存的過程，那么瀏覽器緩存的存儲(chǔ)位置都有哪幾種呢？瀏覽器的緩存，按照其緩存位置可以分為四種：

• Service Worker
• Memory Cache
• Disk Cache
• Push Cache

從緩存位置上來說分為四種，并且各自有優(yōu)先級(jí)，當(dāng)依次查找緩存且都沒有命中的時(shí)候，才會(huì)去請(qǐng)求網(wǎng)絡(luò)。

Service Worker
Service Worker 是運(yùn)行在瀏覽器背后的獨(dú)立線程，一般可以用來實(shí)現(xiàn)緩存功能。使用 Service Worker的話，傳輸協(xié)議必須為 HTTPS。因?yàn)?Service Worker 中涉及到請(qǐng)求攔截，所以必須使用 HTTPS 協(xié)議來保障安全。Service Worker 的緩存與瀏覽器其他內(nèi)建的緩存機(jī)制不同，它可以讓我們自由控制緩存哪些文件、如何匹配緩存、如何讀取緩存，并且緩存是持續(xù)性的。

Service Worker 實(shí)現(xiàn)緩存功能一般分為三個(gè)步驟：首先需要先注冊(cè) Service Worker，然后監(jiān)聽到 install 事件以后就可以緩存需要的文件，那么在下次用戶訪問的時(shí)候就可以通過攔截請(qǐng)求的方式查詢是否存在緩存，存在緩存的話就可以直接讀取緩存文件，否則就去請(qǐng)求數(shù)據(jù)。

當(dāng) Service Worker 沒有命中緩存的時(shí)候，我們需要去調(diào)用 fetch 函數(shù)獲取數(shù)據(jù)。也就是說，如果我們沒有在 Service Worker 命中緩存的話，會(huì)根據(jù)緩存查找優(yōu)先級(jí)去查找數(shù)據(jù)。但是不管我們是從 Memory Cache 中還是從網(wǎng)絡(luò)請(qǐng)求中獲取的數(shù)據(jù)，瀏覽器都會(huì)顯示我們是從 Service Worker 中獲取的內(nèi)容。

Memory Cache
Memory Cache 也就是內(nèi)存中的緩存，主要包含的是當(dāng)前中頁(yè)面中已經(jīng)抓取到的資源,例如頁(yè)面上已經(jīng)下載的樣式、腳本、圖片等。讀取內(nèi)存中的數(shù)據(jù)肯定比磁盤快,內(nèi)存緩存雖然讀取高效，可是緩存持續(xù)性很短，會(huì)隨著進(jìn)程的釋放而釋放。 一旦我們關(guān)閉 Tab 頁(yè)面，內(nèi)存中的緩存也就被釋放了。

那么既然內(nèi)存緩存這么高效，我們是不是能讓數(shù)據(jù)都存放在內(nèi)存中呢？
這是不可能的。計(jì)算機(jī)中的內(nèi)存一定比硬盤容量小得多，操作系統(tǒng)需要精打細(xì)算內(nèi)存的使用，所以能讓我們使用的內(nèi)存必然不多。

當(dāng)我們?cè)L問過頁(yè)面以后，再次刷新頁(yè)面，可以發(fā)現(xiàn)很多數(shù)據(jù)都來自于內(nèi)存緩存

內(nèi)存緩存中有一塊重要的緩存資源是preloader相關(guān)指令（例如）下載的資源。總所周知preloader的相關(guān)指令已經(jīng)是頁(yè)面優(yōu)化的常見手段之一，它可以一邊解析js/css文件，一邊網(wǎng)絡(luò)請(qǐng)求下一個(gè)資源。

需要注意的事情是，內(nèi)存緩存在緩存資源時(shí)并不關(guān)心返回資源的HTTP緩存頭Cache-Control是什么值，同時(shí)資源的匹配也并非僅僅是對(duì)URL做匹配，還可能會(huì)對(duì)Content-Type，CORS等其他特征做校驗(yàn)。

Disk Cache
Disk Cache 也就是存儲(chǔ)在硬盤中的緩存，讀取速度慢點(diǎn)，但是什么都能存儲(chǔ)到磁盤中，比之 Memory Cache 勝在容量和存儲(chǔ)時(shí)效性上。

在所有瀏覽器緩存中，Disk Cache 覆蓋面基本是最大的。它會(huì)根據(jù) HTTP Herder 中的字段判斷哪些資源需要緩存，哪些資源可以不請(qǐng)求直接使用，哪些資源已經(jīng)過期需要重新請(qǐng)求。并且即使在跨站點(diǎn)的情況下，相同地址的資源一旦被硬盤緩存下來，就不會(huì)再次去請(qǐng)求數(shù)據(jù)。絕大部分的緩存都來自 Disk Cache，關(guān)于 HTTP 的協(xié)議頭中的緩存字段，我們會(huì)在下文進(jìn)行詳細(xì)介紹。

瀏覽器會(huì)把哪些文件丟進(jìn)內(nèi)存中？哪些丟進(jìn)硬盤中？
關(guān)于這點(diǎn)，網(wǎng)上說法不一，不過以下觀點(diǎn)比較靠得住：
- 對(duì)于大文件來說，大概率是不存儲(chǔ)在內(nèi)存中的，反之優(yōu)先
- 當(dāng)前系統(tǒng)內(nèi)存使用率高的話，文件優(yōu)先存儲(chǔ)進(jìn)硬盤

Push Cache
Push Cache（推送緩存）是 HTTP/2 中的內(nèi)容，當(dāng)以上三種緩存都沒有命中時(shí)，它才會(huì)被使用。它只在會(huì)話（Session）中存在，一旦會(huì)話結(jié)束就被釋放，并且緩存時(shí)間也很短暫，在Chrome瀏覽器中只有5分鐘左右，同時(shí)它也并非嚴(yán)格執(zhí)行HTTP頭中的緩存指令。

Push Cache 在國(guó)內(nèi)能夠查到的資料很少，也是因?yàn)?HTTP/2 在國(guó)內(nèi)不夠普及。這里推薦閱讀Jake Archibald的 HTTP/2 push is tougher than I thought 這篇文章，文章中的幾個(gè)結(jié)論：

• 所有的資源都能被推送，并且能夠被緩存,但是 Edge 和 Safari 瀏覽器支持相對(duì)比較差
• 可以推送 no-cache 和 no-store 的資源
• 一旦連接被關(guān)閉，Push Cache 就被釋放
• 多個(gè)頁(yè)面可以使用同一個(gè)HTTP/2的連接，也就可以使用同一個(gè)Push Cache。這主要還是依賴瀏覽器的實(shí)現(xiàn)而定，出于對(duì)性能的考慮，有的瀏覽器會(huì)對(duì)相同域名但不同的tab標(biāo)簽使用同一個(gè)HTTP連接。
• Push Cache 中的緩存只能被使用一次
• 瀏覽器可以拒絕接受已經(jīng)存在的資源推送
• 你可以給其他域名推送資源

如果以上四種緩存都沒有命中的話，那么只能發(fā)起請(qǐng)求來獲取資源了。

那么為了性能上的考慮，大部分的接口都應(yīng)該選擇好緩存策略，

訪問緩存優(yōu)先級(jí)（三級(jí)緩存原理 ）

• 先在內(nèi)存中查找,如果有,直接加載。
• 如果內(nèi)存中不存在,則在硬盤中查找,如果有直接加載。
• 如果硬盤中也沒有,那么就進(jìn)行網(wǎng)絡(luò)請(qǐng)求。
• 請(qǐng)求獲取的資源緩存到硬盤和內(nèi)存。

在chrome瀏覽器中的控制臺(tái)Network中size欄通常會(huì)有三種狀態(tài)

• from memory cache：從內(nèi)存中拿到的資源
• from disk cache：從磁盤中讀取到的資源
• 資源本身大小數(shù)值：當(dāng)http狀態(tài)為200是實(shí)實(shí)在在從瀏覽器獲取的資源，當(dāng)http狀態(tài)為304時(shí)該數(shù)字是與服務(wù)端通信報(bào)文的大小，并不是該資源本身的大小，該資源是從本地獲取的

狀態(tài)類型說明

200	form memory cache	不請(qǐng)求網(wǎng)絡(luò)資源，資源在內(nèi)存當(dāng)中，一般腳本、字體、圖片會(huì)存在內(nèi)存當(dāng)中。
200	form disk ceche	不請(qǐng)求網(wǎng)絡(luò)資源，在磁盤當(dāng)中，一般非腳本會(huì)存在內(nèi)存當(dāng)中，如css等。
200	資源大小數(shù)值	資源大小數(shù)值 從服務(wù)器下載最新資源。
304	報(bào)文大小	請(qǐng)求服務(wù)端發(fā)現(xiàn)資源沒有更新，使用本地資源，即命中協(xié)商緩存。

四 實(shí)際場(chǎng)景應(yīng)用緩存策略

1.頻繁變動(dòng)的資源：Cache-Control: no-cache

對(duì)于頻繁變動(dòng)的資源，首先需要使用Cache-Control: no-cache 使瀏覽器每次都請(qǐng)求服務(wù)器，然后配合 ETag 或者 Last-Modified 來驗(yàn)證資源是否有效。這樣的做法雖然不能節(jié)省請(qǐng)求數(shù)量，但是能顯著減少響應(yīng)數(shù)據(jù)大小。

2.不常變化的資源：Cache-Control: max-age=31536000

通常在處理這類資源時(shí)，給它們的 Cache-Control 配置一個(gè)很大的 max-age=31536000 (一年)，這樣瀏覽器之后請(qǐng)求相同的 URL 會(huì)命中強(qiáng)制緩存。而為了解決更新的問題，就需要在文件名(或者路徑)中添加 hash， 版本號(hào)等動(dòng)態(tài)字符，之后更改動(dòng)態(tài)字符，從而達(dá)到更改引用 URL 的目的，讓之前的強(qiáng)制緩存失效 (其實(shí)并未立即失效，只是不再使用了而已)。
在線提供的類庫(kù) (如 jquery-3.3.1.min.js, lodash.min.js 等) 均采用這個(gè)模式。

五 用戶行為對(duì)緩存的影響：

所謂用戶行為對(duì)瀏覽器緩存的影響，指的就是用戶在瀏覽器如何操作時(shí)，會(huì)觸發(fā)怎樣的緩存策略。主要有 3 種：

• 打開網(wǎng)頁(yè)，地址欄輸入地址： 查找 disk cache 中是否有匹配。如有則使用；如沒有則發(fā)送網(wǎng)絡(luò)請(qǐng)求。
• 普通刷新 (F5)：因?yàn)?TAB 并沒有關(guān)閉，因此 memory cache 是可用的，會(huì)被優(yōu)先使用(如果匹配的話)。其次才是 disk cache。
• 強(qiáng)制刷新 (Ctrl + F5)：瀏覽器不使用緩存，因此發(fā)送的請(qǐng)求頭部均帶有 Cache-control: no-cache(為了兼容，還帶了 Pragma: no-cache),服務(wù)器直接返回 200 和最新內(nèi)容

參考：

• HTTP強(qiáng)緩存和協(xié)商緩存https://segmentfault.com/a/1190000008956069
• 深入理解瀏覽器的緩存機(jī)制 https://www.jianshu.com/p/54cc04190252
• 徹底理解瀏覽器的緩存機(jī)制（http緩存機(jī)制）https://www.mwcxs.top/page/565.html

總結(jié)

以上是生活随笔為你收集整理的【浏览器】浏览器缓存的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。