項目中有 前端目錄,前端目錄下有多個入口(每一個入口進行單獨的打包),經過 webpack splitchunk 插件,每次打包時,都會把全部入口的 react 庫獨立抽離出來,抽離後的文件命名爲 chunkname.contenthash.js;前端
打包後發現,每一個入口抽離出來的 react chunk 都不同,有多少個入口,最終打包 就有 多少個 react chunk文件,每一個文件的 hash 名字都不同;react
理論上,因爲單獨抽離的只有 react,不管有多少個入口,打包出來的 react chunk 內容應該都是同樣的,但實際狀況倒是有多個 react chunk,這種狀況明顯不利於客戶端的緩存持久化;webpack
如上圖所示,不一樣的文件,對應位置的數字都不同,致使文件內容都不一致web
瞭解 webpack 的原理的話,能夠知道,上圖所示的兩個數字分別是 chunkId 和 moduleId緩存
至此,問題基本清楚了,因爲 多個入口 是分別打包的,而 react chunk 分配到的 moduleId 和 chunkId 都是隨機生成的,因此不一樣入口的 react chunk 的 moduleId 和 chunkId 都不同;同理同一入口屢次打包,它的 react chunk 分配到的 moduleId 和 chunkId 也會有可能不同;插件
目的是要固化 chunkId 和 moduleId 的分配,有兩種解決路徑:a、能夠本身寫插件和自定義方案進行 id 的分配;b、webpack 官方已經提供了相關插件進行處理;3d
瞭解過 webpack 的官方解決方案後,決定直接使用官方方案(咱們本身寫插件的話,方案也和官方的方案同樣);cdn
官方文檔可參考:webpack.js.org/configurati…blog
修改 webpack 配置文檔
a. chunkId 配置爲 由包含模塊定義的名字,與 splitChunk 共同工做,能夠固化 chunkId;
b. moduleId 配置爲 對應模塊的完整路徑 的 hash 值,避免 每次打包時 moduleId 隨機分配數字;
檢驗成果,從新打包
以下圖,react chunk 收斂到只有一個,不一樣入口均可以服用該 chunk,解決持久緩存的問題