1.缓存：
1.作用：
每次构建的时候只构建我们修改过的文件，
对于没有修改过的文件就不要重新参与编译了。
2.对什么缓存：
babel缓存，文件资源缓存
3.为什么要缓存：
babel是对js代码进行编译处理的
类似与HRM，类似于HRM， 有100个js，其中一个js变了，另外99个js没有变 就用这缓存的，不用重新构建 但是在生产环境下没有这个功能，因为HRM基于devServer，生产环境没有devServer
2.babel缓存：
1.作用：第二次构建时，会读取之前的缓存，让第二次打包构建速度更快
2.用法：
cacheDirectory：true
{
test: /\.js$/,
exclude: /node_modules/,
loader: 'babel-loader',
options: {
presets: [
['@babel/preset-env',]
],
/*开启babel缓存
第二次构建时，会读取之前的缓存
*/
cacheDirectory: true,
}
},
3.资源缓存：
强制缓存后，修改了文件重新构建刷新也不会变
原因：资源在强制缓存期间不会访问服务器，是直接读取缓存
解决方法：给资源加版本号，资源名字变了就会重新请求，没有变就不会请求
filename: 'js/built.[hash:10].js',
作用：让代码上线运行缓存更好
1.hash:每次打包都会生成一次唯一的hash值， 不管文件有没有变化hash值也会变化（js，css的hash值是一样的）
2.chunkhash:根据chunk生成hash，同一个chunk的hash值是一样的
3.contenthash:根据文件的内容生成hash，不同文件的hash值是一定不一样的
1.hash:
1.hash的弊端：
webpack打包后会生成一次唯一的hash值，但是因为js，css同时使用一个hash值 如果重新打包，会导致缓存全部失败，可能我只修改了一个文件
2.用法：
output: {
filename: 'js/built.[hash:10].js',
path: resolve(__dirname, './build')
},
new MiniCssExtractPlugin({
filename: 'css/built.[hash:10].css'
}),
2.chunkhash:
1.chunkhash的弊端：
根据chunk生成hash值，如果打包来源于同一个chunk那么hash值是一样的； 问题：js和css的hash值还是一样的，因为css是被js引入的，同属一个chunk； 如果重新打包，也会导致缓存全部失败
2.用法：
output: {
filename: 'js/built.[chunkhash:10].js',
path: resolve(__dirname, './build')
},
new MiniCssExtractPlugin({
filename: 'css/built.[chunkhash:10].css'
}),
2.contenthash:
1.contenthash：
根据内容来的，不同的内容hash就不一样；
因此会实现改一个文件，只会变一个文件，其余的hash不会变
推荐使用contenthash
2.用法：
output: {
filename: 'js/built.[contenthash:10].js',
path: resolve(__dirname, './build')
},
new MiniCssExtractPlugin({
filename: 'css/built.[contenthash:10].css'
}),
