前言
最近在看 webpack 如何做持久化緩存的內容，發現其中還是有壹些坑點的，正好有時間就將它們整理總結壹下，讀完本文妳大致能夠明白：
什麽是持久化緩存，為什麽做持久化緩存?
webpack 如何做持久化緩存？
webpack 做緩存的壹些註意點。
持久化緩存
首先我們需要去解釋壹下，什麽是持久化緩存，在現在前後端分離的應用大行其道的背景下，前端 html，css，js 往往是以壹種靜態資源文件的形式存在於服務器，通過接口來獲取數據來展示動態內容。這就涉及到公司如何去部署前端代碼的問題，所以就涉及到壹個更新部署的問題，是先部署頁面，還是先部署資源？
先部署頁面，再部署資源：在二者部署的時間間隔內，如果有用戶訪問頁面，就會在新的頁面結構中加載舊的資源，並且把這個舊版本資源當做新版本緩存起來，其結果就是：用戶訪問到壹個樣式錯亂的頁面，除非手動去刷新，否則在資源緩存過期之前，頁面會壹直處於錯亂的狀態。
先部署資源，再部署頁面：在部署時間間隔內，有舊版本的資源本地緩存的用戶訪問網站，由於請求的頁面是舊版本，資源引用沒有改變，瀏覽器將直接使用本地緩存，這樣屬於正常情況，但沒有本地緩存或者緩存過期的用戶在訪問網站的時候，就會出現舊版本頁面加載新版本資源的情況，導致頁面執行錯誤。
所以我們需要壹種部署策略來保證在更新我們線上的代碼的時候，線上用戶也能平滑地過渡並且正確打開我們的網站。
推薦先看這個回答：大公司裏怎樣開發和部署前端代碼？
當妳讀完上面的回答，大致就會明白，現在比較成熟的持久化緩存方案就是在靜態資源的名字後面加 hash 值，因為每次修改文件生成的 hash 值不壹樣，這樣做的好處在於增量式發布文件，避免覆蓋掉之前文件從而導致線上的用戶訪問失效。
因為只要做到每次發布的靜態資源(css, js, img)的名稱都是獨壹無二的，那麽我就可以：
針對 html 文件：不開啟緩存，把 html 放到自己的服務器上，關閉服務器的緩存，自己的服務器只提供 html 文件和數據接口
針對靜態的 js，css，圖片等文件：開啟 cdn 和緩存，將靜態資源上傳到 cdn 服務商，我們可以對資源開啟長期緩存，因為每個資源的路徑都是獨壹無二的，所以不會導致資源被覆蓋，保證線上用戶訪問的穩定性。
每次發布更新的時候，先將靜態資源(js, css, img) 傳到 cdn 服務上，然後再上傳 html 文件，這樣既保證了老用戶能否正常訪問，又能讓新用戶看到新的頁面。
上面大致介紹了下主流的前端持久化緩存方案，那麽我們為什麽需要做持久化緩存呢？
用戶使用瀏覽器第壹次訪問我們的站點時，該頁面引入了各式各樣的靜態資源，如果我們能做到持久化緩存的話，可以在 /happylindz/blog.git
cd blog/code/multiple-page-webpack-demo
npm install閱讀下面的內容之前我強烈建議妳看下我之前的文章：深入理解 webpack 文件打包機制，理解 webpack 文件的打包的機制有助於妳更好地實現持久化緩存。
例子大概是這樣描述的：它由兩個頁面組成 pageA 和 pageB
// src/pageA.js
import componentA from './common/componentA';
// 使用到 jquery 第三方庫，需要抽離，避免業務打包文件過大
import $ from 'jquery';
// 加載 css 文件，壹部分為公***樣式，壹部分為獨有樣式，需要抽離
import './css/common.css'
import './css/pageA.css';
console.log(componentA);
console.log($.trim(' do something '));
// src/pageB.js
// 頁面 A 和 B 都用到了公***模塊 componentA，需要抽離，避免重復加載
import componentA from './common/componentA';
import componentB from './common/componentB';
import './css/common.css'
import './css/pageB.css';
console.log(componentA);
console.log(componentB);
// 用到異步加載模塊 asyncComponent，需要抽離，加載首屏速度
document.getElementById('xxxxx').addEventListener('click', () => {
import( /* webpackChunkName: "async" */
'./common/asyncComponent.js').then((async) => {
async();
})
})
// 公***模塊基本長這樣
export default "component X";上面的頁面內容基本簡單涉及到了我們拆分模塊的三種模式：拆分公***庫，按需加載和拆分公***模塊。那麽接下來要來配置 webpack：
const path = require('path');
const webpack = require('webpack');
const ExtractTextPlugin = require('extract-text-webpack-plugin');
module.exports = {
entry: {
pageA: [path.resolve(dirname, './src/pageA.js')],
pageB: path.resolve(dirname, './src/pageB.js'),
},
output: {
path: path.resolve(dirname, './dist'),
filename: 'js/[name].[chunkhash:8].js',
chunkFilename: 'js/[name].[chunkhash:8].js'
},
module: {
rules: [
{
// 用正則去匹配要用該 loader 轉換的 CSS 文件
test: /.css$/,
use: ExtractTextPlugin.extract({
fallback: "style-loader",
use: ["css-loader"]
})
}
]
},
plugins: [
new webpack.optimize.CommonsChunkPlugin({
name: 'common',
minChunks: 2,
}),
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor',
minChunks: ({ resource }) => (
resource && resource.indexOf('node_modules') >= 0 && resource.match(/.js$/)
)
}),
new ExtractTextPlugin({
filename: `css/[name].[chunkhash:8].css`,
}),
]
}第壹個 CommonsChunkPlugin 用於抽離公***模塊，相當於是說 webpack 大佬，如果妳看到某個模塊被加載兩次即以上，那麽請妳幫我移到 common chunk 裏面，這裏 minChunks 為 2，粒度拆解最細，妳可以根據自己的實際情況，看選擇是用多少次模塊才將它們抽離。
第二個 CommonsChunkPlugin 用來提取第三方代碼，將它們進行抽離，判斷資源是否來自 node_modules，如果是，則說明是第三方模塊，那就將它們抽離。相當於是告訴 webpack 大佬，如果妳看見某些模塊是來自 node_modules 目錄的，並且名字是 .js 結尾的話，麻煩把他們都移到 vendor chunk 裏去，如果 vendor chunk 不存在的話，就創建壹個新的。
這樣配置有什麽好處，隨著業務的增長，我們依賴的第三方庫代碼很可能會越來越多，如果我們專門配置壹個入口來存放第三方代碼，這時候我們的 webpack.config.js 就會變成：
// 不利於拓展
module.exports = {
entry: {
app: './src/main.js',
vendor: [
'vue',
'axio',
'vue-router',
'vuex',
// more
],
},
} 第三個 ExtractTextPlugin 插件用於將 css 從打包好的 js 文件中抽離，生成獨立的 css 文件，想象壹下，當妳只是修改了下樣式，並沒有修改頁面的功能邏輯，妳肯定不希望妳的 js 文件 hash 值變化，妳肯定是希望 css 和 js 能夠相互分開，且互不影響。
運行 webpack 後可以看到打包之後的效果:
├── css
│ ├── common.2beb7387.css
│ ├── pageA.d178426d.css
│ └── pageB.33931188.css
└── js
├── async.03f28faf.js
├── common.2beb7387.js
├── pageA.d178426d.js
├── pageB.33931188.js
└── vendor.22a1d956.js可以看出 css 和 js 已經分離，並且我們對模塊進行了拆分，保證了模塊 chunk 的唯壹性，當妳每次更新代碼的時候，會生成不壹樣的 hash 值。
唯壹性有了，那麽我們需要保證 hash 值的穩定性，試想下這樣的場景，妳肯定不希望妳修改某部分的代碼(模塊，css)導致了文件的 hash 值全變了，那麽顯然是不明智的，那麽我們去做到 hash 值變化最小化呢？
換句話說，我們就要找出 webpack 編譯中會導致緩存失效的因素，想辦法去解決或優化它？
影響 chunkhash 值變化主要由以下四個部分引起的：
包含模塊的源代碼
webpack 用於啟動運行的 runtime 代碼
webpack 生成的模塊 moduleid(包括包含模塊 id 和被引用的依賴模塊 id)
chunkID
這四部分只要有任意部分發生變化，生成的分塊文件就不壹樣了，緩存也就會失效，下面就從四個部分壹壹介紹：
壹、源代碼變化：
顯然不用多說，緩存必須要刷新，不然就有問題了
二、webpack 啟動運行的 runtime 代碼：
看過我之前的文章：深入理解 webpack 文件打包機制 就會知道，在 webpack 啟動的時候需要執行壹些啟動代碼。
(function(modules) {
window["webpackJsonp"] = function webpackJsonpCallback(chunkIds, moreModules) {
// ...
};
function webpack_require(moduleId) {
// ...
}
webpack_require.e = function requireEnsure(chunkId, callback) {
// ...
script.src = webpack_require.p + "" + chunkId + "." + ({"0":"pageA","1":"pageB","3":"vendor"}[chunkId]||chunkId) + "." + {"0":"e72ce7d4","1":"69f6bbe3","2":"9adbbaa0","3":"53fa02a7"}[chunkId] + ".js";
};
})([]);大致內容像上面這樣，它們是 webpack 的壹些啟動代碼，它們是壹些函數，告訴瀏覽器如何加載 webpack 定義的模塊。
其中有壹行代碼每次更新都會改變的，因為啟動代碼需要清楚地知道 chunkid 和 chunkhash 值得對應關系，這樣在異步加載的時候才能正確地拼接出異步 js 文件的路徑。
那麽這部分代碼最終放在哪個文件呢？因為我們剛才配置的時候最後生成的 common chunk 模塊，那麽這部分運行時代碼會被直接內置在裏面，這就導致了，我們每次更新我們業務代碼(pageA, pageB, 模塊)的時候， common chunkhash 會壹直變化，但是這顯然不符合我們的設想，因為我們只是要用 common chunk 用來存放公***模塊(這裏指的是 componentA)，那麽我 componentA 都沒去修改，憑啥 chunkhash 需要變了。
所以我們需要將這部分 runtime 代碼抽離成單獨文件。
module.exports = {
// ...
plugins: [
// ...
// 放到其他的 CommonsChunkPlugin 後面
new webpack.optimize.CommonsChunkPlugin({
name: 'runtime',
minChunks: Infinity,
}),
]
}這相當於是告訴 webpack 幫我把運行時代碼抽離，放到單獨的文件中。
├── css
│ ├── common.4cc08e4d.css
│ ├── pageA.d178426d.css
│ └── pageB.33931188.css
└── js
├── async.03f28faf.js
├── common.4cc08e4d.js
├── pageA.d178426d.js
├── pageB.33931188.js
├── runtime.8c79fdcd.js
└── vendor.cef44292.js多生成了壹個 runtime.xxxx.js，以後妳在改動業務代碼的時候，common chunk 的 hash 值就不會變了，取而代之的是 runtime chunk hash 值會變，既然這部分代碼是動態的，可以通過 chunk-manifest-webpack-plugin 將他們 inline 到 html 中，減少壹次網絡請求。
三、webpack 生成的模塊 moduleid
在 webpack2 中默認加載 OccurrenceOrderPlugin 這個插件，OccurrenceOrderPlugin 插件會按引入次數最多的模塊進行排序，引入次數的模塊的 moduleId 越小，但是這仍然是不穩定的，隨著妳代碼量的增加，雖然代碼引用次數的模塊 moduleId 越小，越不容易變化，但是難免還是不確定的。
默認情況下，模塊的 id 是這個模塊在模塊數組中的索引。OccurenceOrderPlugin 會將引用次數多的模塊放在前面，在每次編譯時模塊的順序都是壹致的，如果妳修改代碼時新增或刪除了壹些模塊，這將可能會影響到所有模塊的 id。
最佳實踐方案是通過 HashedModuleIdsPlugin 這個插件，這個插件會根據模塊的相對路徑生成壹個長度只有四位的字符串作為模塊的 id，既隱藏了模塊的路徑信息，又減少了模塊 id 的長度。
這樣壹來，改變 moduleId 的方式就只有文件路徑的改變了，只要妳的文件路徑值不變，生成四位的字符串就不變，hash 值也不變。增加或刪除業務代碼模塊不會對 moduleid 產生任何影響。
module.exports = {
plugins: [
new webpack.HashedModuleIdsPlugin(),
// 放在最前面
// ...
]
}四、chunkID
實際情況中分塊的個數的順序在多次編譯之間大多都是固定的, 不太容易發生變化。
這裏涉及的只是比較基礎的模塊拆分，還有壹些其它情況沒有考慮到，比如異步加載組件中包含公***模塊，可以再次將公***模塊進行抽離。形成異步公*** chunk 模塊。有想深入學習的可以看這篇文章：Webpack 大法之 Code Splitting
webpack 做緩存的壹些註意點
CSS 文件 hash 值失效的問題
不建議線上發布使用 DllPlugin 插件
CSS 文件 hash 值失效的問題：
ExtractTextPlugin 有個比較嚴重的問題，那就是它生成文件名所用的[chunkhash]是直接取自於引用該 css 代碼段的 js chunk ；換句話說，如果我只是修改 css 代碼段，而不動 js 代碼，那麽最後生成出來的 css 文件名依然沒有變化。
所以我們需要將 ExtractTextPlugin 中的 chunkhash 改為 contenthash，顧名思義，contenthash 代表的是文本文件內容的 hash 值，也就是只有 style 文件的 hash 值。這樣編譯出來的 js 和 css 文件就有獨立的 hash 值了。
module.exports = {
plugins: [
// ...
new ExtractTextPlugin({
filename: `css