覽器緩存對于前端一點都不陌生，最常見的就是，新版本上線了，測試卻說這怎么還沒有變化呢？使用 ctr + F5 強制刷新之后，立馬就好了。或者清除瀏覽器緩存，按住ctr+shift+delete，彈出如圖：

我們會發現目前瀏覽器緩存的圖片和文件的大小?；蛘哌M入chrome://chrome-urls/找到chrome://cache/ 就可以看到所有緩存的地址列表。對于瀏覽器緩存，前端對它是又愛又恨，有時想保留，有時想禁掉，所以看看瀏覽器緩存到底是怎樣的？

一、什么是瀏覽器緩存？

瀏覽器緩存就是瀏覽器根據 url 第一次訪問網站之后，將網站的 html、css、js、圖片等文件復制一份保留到瀏覽器中，當你二次訪問這個 url 的網站時，如果網站沒有明確表示有更新時，瀏覽器直接在緩存中查找內容，不會再次請求網頁內容，只有網頁明確表示有更新時，瀏覽器才會向服務器發起網路請求，再次下載網頁。

如上圖，百度首頁就是使用了緩存機制，首次訪問之后 web資源被緩存，在后面重復請求中，資源直接在緩存中讀取，而不是向服務器請求資源。

二、為什么使用緩存？

2.1、為什么很多網站二次打開速度很快？

網頁二次打開很快，主要原因是第一次加載頁面過程中，緩存了部分耗時數據，這一現象，對于單頁面應用開發非常明顯。

上一篇文章《瀏覽器工作原理》中，瀏覽器工作流程介紹，輸入網址回車以后瀏覽器向服務器發起服務之前，會現在瀏覽器緩存中查詢是否有需要的文件？如果有則直接在緩存中獲取文件，避免向服務器請求和下載文件，所以節省了一部分時間。

2.2、瀏覽器緩存優點

1、減少網絡帶寬消耗

對于網站運營者或者訪問網頁的用戶，帶寬就代表著 money ，過多的消耗帶寬，我們服務器配置就得升級，使用瀏覽器緩存之后，就會減少網絡流量，降低運營成本。

2、降低服務器壓力

使用瀏覽器緩存之后，除第一次訪問需要向服務器請求網站全部資源，后續訪問可以重復使用瀏覽器本地緩存，減少對服務器的請求，間接降低服務器的壓力，同時，搜索引擎的爬蟲也會根據緩存過期機制降低抓取的頻率，也可以降低服務器壓力。

3、減少網絡延遲，加快網頁加載

瀏覽器緩存 web資源后，減少網絡請求，可以更快速地獲取到服務器返回數據，同時使用瀏覽器緩存內的文件比服務器獲取快很多，所以網頁加載速度明顯快很多。

三、瀏覽器的緩存規則

對于瀏覽器端的緩存來講，這些規則是在 http 協議和 meta 標簽中定義的。分別從兩個維度：新鮮度和校驗值，規定瀏覽器是否可以直接使用緩存中的副本，還是直接從服務器獲取最新資源。

3.1、新鮮度(過期)：瀏覽器緩存的有效期，緩存必須滿足以下兩個條件，瀏覽器才會認為是最新的，可以直接使用。

• 含有完整的過期時間控制頭信息，并在有效期內。
• 瀏覽器已經使用過這個副本，并且在會話中已經檢查過新鮮度。

3.2、校驗值(驗證)：服務器返回資源的時候，會在響應頭信息中帶上資源實體標簽 Entity Tag，可以用來作為瀏覽器再次請求過程的校驗標識，如果發現校驗標識不匹配，說明資源已經被修改過或過期，瀏覽器需要重新請求資源。

四、如何控制緩存？

緩存規則可以設置在html的meta標簽，也可以設置在http協議頭內。

4.1、前端 html 中 meta 標簽

在 html 頁面中加入緩存設置，代碼如下：

<meta http-equiv="Pragma" content="no-cache"  />
<!-- Pragma是http1.0版本中給客戶端設定緩存方式之一 -->

上邊代碼，禁止瀏覽器緩存，瀏覽器每次訪問網頁都要去服務器請求。事實這種禁用緩存形式作用有限：

• 只有IE瀏覽器才能標識這段 meta 的含義，其他主流瀏覽器僅認識 “Cache-Control:no-store” 的 meta 標簽。
• 在IE瀏覽器中，并不一定添加 pragma，但是會讓當前網頁每次都會向服務器發送請求。

4.2、HTTP協議頭

http請求和響應頭中，與緩存相關的常見類型：

各種類型之間的關系和區別：

• Cache-Control 與 Expires：它兩作用一樣，都表明當前資源的有效期，控制瀏覽器是取緩存還是直接向服務器獲取，Cache-Control可以設置的更細致，如果同時設置，它的優先級高于Expires。
• Last-Modified / ETag 與 Cache-Control / Expires：配置Last-Modified/ETag的情況下，瀏覽器再次訪問URL的資源，還是會發送請求到服務器，詢問文件是否已經修改，如果沒有，服務器會給瀏覽器返回304，瀏覽器直接從本地緩存中取就好了，反之，服務器會直接向瀏覽器返回數據。Cache-Control / Expires 檢測本地緩存是否還在有效期內，在有效期內，直接使用本地緩存，阻止發送請求。如果同時設置，Cache-Control / Expiress 優先級更高。一般情況下，兩者配合使用，因為即使服務器設置緩存時間, 當用戶點擊“刷新”按鈕時，瀏覽器會忽略緩存繼續向服務器發送請求，這時Last-Modified/ETag將能夠很好利用304，從而減少響應開銷。
• Last-Modified 與 ETag：ETag主要是為了解決Last-Modified比較難解決的問題：1、Last-Modified標注的最后修改只能精確到秒級，如果某些文件在1秒鐘以內，被修改多次的話，它將不能準確標注文件的新鮮度。2、如果某些文件會被定期生成，當有時內容并沒有任何變化，但Last-Modified卻改變了，導致文件沒法使用緩存。3、有可能存在服務器沒有準確獲取文件修改時間，或者與代理服務器時間不一致等情形。ETag是服務器自動生成或開發者生成對應資源在服務器的唯一標識符，能夠更加精準控制緩存。兩者可以一起使用，服務器優先驗證ETag，一致時，才會繼續比對Last-Mofifed，才決定是否要返回304。

五、不能緩存的請求

并不是所有的請求都能被緩存，無法被緩存的有：

• post 請求無法被緩存。
• 需要根據cookie、認證信息等決定輸入內容的動態請求不能被緩存。
• http響應頭中不包含Last-Modified/ETag，也不包含Cache-Control/Expiress的請求無法被緩存。
• http信息頭明確設置Cache-Control:no-cache,pragma:no-cache或Cache-Control:max-age=0瀏覽器不緩存時。

者：kevinylzhao，騰訊音樂前端開發工程師

瀏覽器緩存策略對于前端開發同學來說不陌生，大家都有一定的了解，但如果沒有系統的歸納總結，可能三言兩語很難說明白，甚至說錯，尤其在面試過程中感觸頗深，很多候選人對這類基礎知識竟然都是一知半解，說出幾個概念就沒了，所以重新歸納總結下，溫故而知新。

Web 緩存介紹

• Web 緩存是指一個 Web 資源（如 html 頁面，圖片，js，數據等）存在于 Web 服務器和客戶端（瀏覽器）之間的副本。
• 緩存會根據進來的請求保存輸出內容的副本；當下一個請求來到的時候，如果是相同的 URL，緩存會根據緩存機制決定是直接使用副本響應訪問請求，還是向源服務器再次發送請求。

Web 緩存的好處

• 減少網絡延遲，加快頁面打開速度
• 減少網絡帶寬消耗
• 降低服務器壓力
• ...

HTTP 的緩存機制

簡化的流程如下

根據什么規則緩存

1. 新鮮度（過期機制）：也就是緩存副本有效期。一個緩存副本必須滿足以下條件，瀏覽器會認為它是有效的，足夠新的：

• 含有完整的過期時間控制頭信息（HTTP 協議報頭），并且仍在有效期內；
• 瀏覽器已經使用過這個緩存副本，并且在一個會話中已經檢查過新鮮度；

2. 校驗值（驗證機制）：服務器返回資源的時候有時在控制頭信息帶上這個資源的實體標簽 Etag（Entity Tag），它可以用來作為瀏覽器再次請求過程的校驗標識。如果發現校驗標識不匹配，說明資源已經被修改或過期，瀏覽器需求重新獲取資源內容。

HTTP 緩存的兩個階段

瀏覽器緩存一般分為兩類：強緩存（也稱本地緩存）和協商緩存（也稱弱緩存）。

本地緩存階段

瀏覽器發送請求前，會先去緩存里查看是否命中強緩存，如果命中，則直接從緩存中讀取資源，不會發送請求到服務器。否則，進入下一步。

協商緩存階段

當強緩存沒有命中時，瀏覽器一定會向服務器發起請求。服務器會根據 Request Header 中的一些字段來判斷是否命中協商緩存。如果命中，服務器會返回 304 響應，但是不會攜帶任何響應實體，只是告訴瀏覽器可以直接從瀏覽器緩存中獲取這個資源。如果本地緩存和協商緩存都沒有命中，則從直接從服務器加載資源。

啟用&關閉緩存

按照本地緩存階段和協商緩存階段分類：

1. 使用 HTML Meta 標簽 　　 Web 開發者可以在 HTML 頁面的節點中加入標簽，如下：

上述代碼的作用是告訴瀏覽器當前頁面不被緩存，事實上這種禁用緩存的形式用處很有限：

a. 僅有 IE 才能識別這段 meta 標簽含義，其它主流瀏覽器僅識別“Cache-Control: no-store”的 meta 標簽。

b. 在 IE 中識別到該 meta 標簽含義，并不一定會在請求字段加上 Pragma，但的確會讓當前頁面每次都發新請求（僅限頁面，頁面上的資源則不受影響）。

2. 使用緩存有關的 HTTP 消息報頭 這里需要了解 HTTP 的基礎知識。一個 URI 的完整 HTTP 協議交互過程是由 HTTP 請求和 HTTP 響應組成的。有關 HTTP 詳細內容可參考《Hypertext Transfer Protocol — HTTP/1.1》、《HTTP 權威指南》等。

在 HTTP 請求和響應的消息報頭中，常見的與緩存有關的消息報頭有：

上圖中只是常用的消息報頭，下面來看下不同字段之間的關系和區別：

1. Cache-Control 與 Expires
2. Cache-Control：HTTP1.1 提出的特性，為了彌補 Expires 缺陷加入的，提供了更精確細致的緩存功能。詳細了解詳細看幾個常見的指令：_ max-age：功能和 Expires 類似，但是后面跟一個以“秒”為單位的相對時間，來供瀏覽器計算過期時間。_ no-cache：提供了過期驗證機制。(在 Chrome 的 devtools 中勾選 Disable cache 選項，發送的請求會去掉 If-Modified-Since 這個 Header。同時設置 Cache-Control:no-cache Pragma:no-cache，每次請求均為 200)

• no-store：表示當前請求資源禁用緩存；
• public：表示緩存的版本可以被代理服務器或者其他中間服務器識別；
• private：表示只有用戶自己的瀏覽器能夠進行緩存，公共的代理服務器不允許緩存。
• Expires：HTTP1.0 的特性，標識該資源過期的時間點，它是一個絕對值，格林威治時間（Greenwich Mean Time, GMT），即在這個時間點之后，緩存的資源過期；優先級：Cache-Control 優先級高于 Expires，為了兼容，通常兩個頭部同時設置；瀏覽器默認行為：其實就算 Response Header 中沒有設置 Cache-Control 和 Expires，瀏覽器仍然會緩存某些資源，這是瀏覽器的默認行為，是為了提升性能進行的優化，每個瀏覽器的行為可能不一致，有些瀏覽器甚至沒有這樣的優化。

1. Last-Modified 與 ETag
2. Last-Modified(Response Header)與 If-Modified-Since(Request Header)是一對報文頭，屬于 http 1.0。If-Modified-Since 是一個請求首部字段，并且只能用在 GET 或者 HEAD 請求中。Last-Modified 是一個響應首部字段，包含服務器認定的資源作出修改的日期及時間。當帶著 If-Modified-Since 頭訪問服務器請求資源時，服務器會檢查 Last-Modified，如果 Last-Modified 的時間早于或等于 If-Modified-Since 則會返回一個不帶主體的 304 響應，否則將重新返回資源。(注意：在 Chrome 的 devtools 中勾選 Disable cache 選項后，發送的請求會去掉 If-Modified-Since 這個 Header。)

• ETag 與 If-None-Match 是一對報文頭，屬于 http 1.1。ETag 是一個響應首部字段，它是根據實體內容生成的一段 hash 字符串，標識資源的狀態，由服務端產生。If-None-Match 是一個條件式的請求首部。如果請求資源時在請求首部加上這個字段，值為之前服務器端返回的資源上的 ETag，則當且僅當服務器上沒有任何資源的 ETag 屬性值與這個首部中列出的時候，服務器才會返回帶有所請求資源實體的 200 響應，否則服務器會返回不帶實體的 304 響應。
• ETag 能解決什么問題？

a. Last-Modified 標注的最后修改只能精確到秒級，如果某些文件在 1 秒鐘以內，被修改多次的話，它將不能準確標注文件的新鮮度；

b. 某些文件也許會周期性的更改，但是它的內容并不改變(僅僅改變的修改時間)，但 Last-Modified 卻改變了，導致文件沒法使用緩存；

c. 有可能存在服務器沒有準確獲取文件修改時間，或者與代理服務器時間不一致等情形。

• 優先級：ETag 優先級比 Last-Modified 高，同時存在時會以 ETag 為準。

緩存位置

瀏覽器可以在內存、硬盤中開辟一個空間用于保存請求資源副本。我們經常調試時在 DevTools Network 里看到 Memory Cache（內存緩存）和 Disk Cache（硬盤緩存），指的就是緩存所在的位置。請求一個資源時，會按照優先級（Service Worker -> Memory Cache -> Disk Cache -> Push Cache）依次查找緩存，如果命中則使用緩存，否則發起請求。這里先介紹 Memory Cache 和 Disk Cache。

200 from memory cache

表示不訪問服務器，直接從內存中讀取緩存。因為緩存的資源保存在內存中，所以讀取速度較快，但是關閉進程后，緩存資源也會隨之銷毀，一般來說，系統不會給內存分配較大的容量，因此內存緩存一般用于存儲較小文件。同時內存緩存在有時效性要求的場景下也很有用（比如瀏覽器的隱私模式）。

200 from disk cache

表示不訪問服務器，直接從硬盤中讀取緩存。與內存相比，硬盤的讀取速度相對較慢，但硬盤緩存持續的時間更長，關閉進程之后，緩存的資源仍然存在。由于硬盤的容量較大，因此一般用于存儲大文件。

下圖可清晰看出差別：

200 from prefetch cache

在 preload 或 prefetch 的資源加載時，兩者也是均存儲在 http cache，當資源加載完成后，如果資源是可以被緩存的，那么其被存儲在 http cache 中等待后續使用；如果資源不可被緩存，那么其在被使用前均存儲在 memory cache。

CDN Cache

以騰訊 CDN 為例：X-Cache-Lookup:Hit From MemCache 表示命中 CDN 節點的內存；X-Cache-Lookup:Hit From Disktank 表示命中 CDN 節點的磁盤；X-Cache-Lookup:Hit From Upstream 表示沒有命中 CDN。

整體流程

從上圖能感受到整個流程，比如常見兩種刷新場景：

• 當 F5 刷新網頁時，跳過強緩存，但是會檢查協商緩存；
• 當 Ctrl + F5 強制刷新頁面時，直接從服務器加載，跳過強緩存和協商緩存

其他 Web 緩存策略

IndexDB

IndexedDB 就是瀏覽器提供的本地數據庫，能夠在客戶端存儲可觀數量的結構化數據，并且在這些數據上使用索引進行高性能檢索的 API。

異步 API 方法調用完后會立即返回，而不會阻塞調用線程。要異步訪問數據庫，要調用 window 對象 indexedDB 屬性的 open() 方法。該方法返回一個 IDBRequest 對象 (IDBOpenDBRequest)；異步操作通過在 IDBRequest 對象上觸發事件來和調用程序進行通信。

常用異步 API 如下：

在 16 年曾基于 IndexDB 做過一整套緩存策略，有不錯的優化效果：

Service Worker

SW 從 2014 年提出的草案到現在已經發展很成熟了，基于 SW 做離線緩存，讓用戶能夠進行離線體驗，消息推送體驗，離線緩存能力涉及到 Cache 和 CacheStorage 的概念，篇幅有限，不展開了。

LocalStorage

localStorage 屬性允許你訪問一個 Document 源(origin)的對象 Storage 用于存儲當前源的數據，除非用戶人為清除(調用 localStorage api 或者清除瀏覽器數據)， 否則存儲在 localStorage 的數據將被長期保留。

SessionStorage

sessionStorage 屬性允許你訪問一個 session Storage 對象，用于存儲當前會話的數據，存儲在 sessionStorage 里面的數據在頁面會話結束時會被清除。頁面會話在瀏覽器打開期間一直保持，并且重新加載或恢復頁面仍會保持原來的頁面會話。

定義最優緩存策略

• 使用一致的網址：如果您在不同的網址上提供相同的內容，將會多次獲取和存儲該內容。注意：URL 區分大小寫！
• 確定中繼緩存可以緩存哪些資源：對所有用戶的響應完全相同的資源很適合由 CDN 或其他中繼緩存進行緩存；
• 確定每個資源的最優緩存周期：不同的資源可能有不同的更新要求。審查并確定每個資源適合的 max-age；
• 確定網站的最佳緩存層級：對 HTML 文檔組合使用包含內容特征碼的資源網址以及短時間或 no-cache 的生命周期，可以控制客戶端獲取更新的速度；
• 更新最小化：有些資源的更新比其他資源頻繁。如果資源的特定部分（例如 JS 函數或一組 CSS 樣式）會經常更新，應考慮將其代碼作為單獨的文件提供。這樣，每次獲取更新時，剩余內容（例如不會頻繁更新的庫代碼）可以從緩存中獲取，確保下載的內容量最少；
• 確保服務器配置或移除 ETag：因為 Etag 跟服務器配置有關，每臺服務器的 Etag 都是不同的；
• 善用 HTML5 的緩存機制：合理設計啟用 LocalStorage、SessionStorage、IndexDB、SW 等存儲，會給頁面性能帶來明顯提升；
• 結合 Native 的強大存儲能力：善于利用客戶端能力，定制合適的緩存機制，打造極致體驗。

結語

通過了解瀏覽器各種緩存機制和存儲能力特點，結合業務制定合適的緩存策略，善用緩存是基本功，可以用于時常審查負責的業務，可能就會發現個別業務并沒有運用到位，共勉。

存是個老生長談的問題，對于前端工程師來講更是我們的必修課?；蛟S很多人會說我的項目并沒有問題，根本不需要聊什么緩存。如果真的是這樣，只能證明你前端道路才剛剛開始。

背景

小郭今天分享緩存的原因在于：公司的一個核心APP中嵌入了SPA，而且應用核心都分布在SPA中，功能復雜且重。問題出現了：應用核心頁面打開一直處于加載狀態，排除掉弱網環境的原因，重點就在于沒有緩存，每次進入頁面都需要重載DOM和數據，拖慢頁面打開速度。

那應該處理緩存問題呢？接下來小郭從三個方向來講解。

瀏覽器緩存策略

在了解瀏覽器緩存前，我們需要先了解一下相關的概念：cache-control，expires，last-Modified，ETag。

瀏覽器通過請求頭實現緩存，關鍵的請求頭有cache-control，expires，last-Modified，ETag等。我們從時間和空間兩個角度來看瀏覽器緩存。

時間

瀏覽器發送第一次請求：不緩存，服務端根據設定的緩存策略返回相應的header，如：cache-control，expires，last-Modified，ETag。

瀏覽器發送第二次請求：

• 強緩存策略：不需要和服務端通信就決定是否使用緩存，cache-control優先級大于expires① 有cache-control且不過期，返回本地磁盤緩存，狀態值200；② 有expires且不過期，返回本地磁盤緩存，狀態值200。
• 協商緩存策略：需要和服務端通信決定是否用緩存，Etag優先級大于last-Modified。① 有Etag，請求頭添加If-None-Match，值就是上次返回的Etag值，然后發送給服務端。服務端對比If-None-Match與現有的Etag值是否一樣；一樣的話只返回header，狀態碼304，瀏覽器從本地磁盤獲取緩存信息；不一樣走正常流程，返回header+body，狀態碼200；② 有last-Modified，添加請求頭If-Modified-Since，值是上次返回的last-Modified，然后發送給服務端。服務端對比If-Modified-Since與現有的是否一樣；一樣的話返回只返回header，狀態碼304，瀏覽器從本地磁盤獲取緩存信息；不一樣走正常流程，返回header+body，狀態碼200
• 無緩存

空間

• 瀏覽器和服務端：服務端需要決定使用哪種緩存策略并在響應頭返回；前端不需要設置，是瀏覽器本身機制。
• html和靜態資源：通常html不設置緩存，因為其它資源的入口都是html文件；靜態資源（js，css，圖片等）會設置緩存

部署時緩存的問題

如果緩存就按理論上設置，那就太簡單了。在實際應用有個嚴重的問題，我們不僅要緩存代碼，還需要更新代碼。如果靜態資源名字不變，怎么讓瀏覽器即能緩存又能在有新代碼時更新。最簡單的解決方式就是靜態資源路徑添加一個版本值，版本不變就走緩存策略，版本變了就加載新資源。如下：

<script src="xx/xx.js?v=24334452"></script>

然而這種處理方式在部署時有問題。

解決方法：靜態資源和頁面是分開部署

• 先部署頁面再部署靜態資源，會出現用戶訪問到舊的資源
• 先部署靜態資源再部署頁面，會出現沒有緩存用戶加載到新資源而報錯

這些問題的本質是以上的部署方式是“覆蓋式發布”，解決方式是“非覆蓋式發布”。即用靜態資源的文件摘要信息給文件命名，這樣每次更新資源不會覆蓋原來的資源，先將資源發布上去。這時候存在兩種資源，用戶用舊頁面訪問舊資源，然后再更新頁面，用戶變成新頁面訪問新資源，就能做到無縫切換。簡單來說就是給靜態文件名加hash值。

那如何實現呢？

現在前端代碼都用webpack之類的構建工具打包，那么結合webpack該怎么做，怎么才能做到持久化緩存？

webpack持久化緩存

一、webpack給文件名添加hash值是很簡單的，但hash/chunkhash/contenthash要用哪個呢？

官方定義

hash: unique hash generated for every build

chunkhash: hashes based on each chunks' content

contenthash: hashes generated for extracted content

根據分析，contenthash才是我們需要的，內容有更新，hash值才會更新。

二、webpack會打包業務代碼、第三方庫及運行時代碼，為保證緩存互不干擾，應該將它們提取出來。

第三方庫提取方式是設置optimization的splitChunks的cacheGroups。splitChunks能提取模塊，cacheGroups能緩存模塊，并且cacheGroups的配置會覆蓋splitChunks相同配置，既能提取又能緩存，故只需設置cacheGroups。

運行時代碼的提取方式為配置runtimeChunk，默認為false，表示運行時代碼嵌入到不同的chunk文件中；現在將運行時代碼提取出來，并命名為manifest。

module.exports = {
  entry: {
    index: "./src/index.js",
    bar: "./src/bar.js"
  },
  output: {
    filename: "[name].[contenthash].js"
  },
  optimization: {
    splitChunks: {
      cacheGroups: {
        vendor: {
          test:/[\\/]node_modules[\\/]/,
          name: "vendors",
          chunks: "all"
        }
      }
    },
    runtimeChunk: {
      name: "manifest"
    }
  }
};

三、 moduleName 和 chunkName 對文件的影響

module：就是js模塊

chunk：webpack編譯過程中由多個module組成的文件

bundle：bundle是chunk文件的最終狀態，是webpack編譯后的結果

一個文件被分離為3個文件，文件間怎么相互依賴的，會影響彼此打包，解決方法是將moduleId和chunkId改成按照文件路徑生成。

optimization: {
  moduleIds: 'hashed',
  namedModules: true,
  namedChunks: true
}

這樣子moduleId在編譯后的文件是文件目錄的hash值，更加安全。這也是namedChunks在production默認為false的原因，不想依賴的文件路徑在編譯后的文件直接展示，但是為了持久性緩存，這里也只能打開。

四、CSS文件緩存

當css代碼提取成單獨文件，當我們改變css時，怎么保證不影響引用它的js文件呢？配置如下：

plugins: [
  new MiniCssExtractPlugin({
    filename: "[contenthash].css"
  })
]

webpack持久化緩存目標是當且僅當該文件內容變動才改變該文件名字的hash值

const MiniCssExtractPlugin = require("mini-css-extract-plugin");
module.exports = { 
  output: { 
    filename: [name].[contenthash].js, // 讓hash值只在內容變動時更新 
    chunkFilename: [name].[contenthash].js // 動態引入的模塊命名，同上 
  }, 
  module: { 
    rules: [ { 
      test: /\.css$/, 
      use: [ 
        "loader: MiniCssExtractPlugin.loader", // 提取出來css "css-loader" 
      ] 
    } ] 
  }, 
  optimization: { 
    moduleIds: "hashed", // 混淆文件路徑名 
    runtimeChunk: { name: 'manifest' }, // 提取runtime代碼命名為manifest 
    namedModules: true, // 讓模塊id根據路徑設置，避免每增加新模塊，所有id都改變，造成緩存失效的情況 
    namedChunks: true, // 避免增加entrypoint，其他文件都緩存失效 
    cacheGroups: { 
      vendor: { // 提取第三方庫文件 
        test: /[\\/]node_modules[\\/]/, 
        name: 'vendors', chunks: 'all', 
      }, 
    },
  } 
  plugins: [ 
    new webpack.HashedModuleIdsPlugin(), // 與namedModules: true作用一樣 
    new MiniCssExtractPlugin({ 
      filename: "[contenthash].css", // css文件也是按contenthash命名 
      chunkFilename: "[contenthash].css", // 動態引入的css命名，同上 
    }) 
  ], 
}

總結

瀏覽器有其緩存機制，想要既能緩存又能在部署時沒有問題，需要給靜態文件名添加hash值。在webpack中，有些配置能讓我們實現持久化緩存。感興趣的同學可以自行去測試哦！

有任何問題可以在下方留言，想了解更多前端知識歡迎關注公眾號“一郭鮮”，文章也將同步于公眾號，前端學習不迷路