一、搭配postcss-loader进行css前缀补全
npm i postcss-loader autoprefixer -D
首先安装上面两个依赖，postcss其实就相当于js的babel一样，他可以对css进行一操作和转换。
接下来在项目根目录中创建postcss的配置文件postcss.config.js，并初始化配置：
const autoprefixer = require('autoprefixer')
module.exports = {
plugins:[autoprefixer]
}
最后在处理css的loader数组里添加上postcss-loader即可，注意添加顺序。
{
test: /\.css$/, //只检测.css文件
use: [ //执行顺序：从右到左或者从下到上，最末尾的loader最先执行
// "style-loader",//将js中的css通过创建style标签的形式添加到html中，以生效
MiniCssExtractPlugin.loader,//将css通过link引入
"css-loader", //将css资源编译成common.js的模块到js中,
"postcss-loader",// css处理器，类似于js的babel
]
},
二、px自动转rem
在移动端网页开发的过程中，适配是一个很让人头疼的问题，而rem的出现就大大的解决了这个问题。我们都知道rem是一个相对单位，他会根据根元素的font-size自动的进行缩放。那再编写代码的过程中，如何自动的去将px转为rem呢。
px2rem-loader就可以帮到我们
npm i px2rem-loader -D
同样的还是再css的loader里添加上这个loader
{
test: /\.css$/, //只检测.css文件
use: [ //执行顺序：从右到左或者从下到上，最末尾的loader最先执行
// "style-loader",//将js中的css通过创建style标签的形式添加到html中，以生效
MiniCssExtractPlugin.loader,
"css-loader", //将css资源编译成common.js的模块到js中,
"postcss-loader",// css处理器，类似于js的babel
{
loader: "px2rem-loader", //自动将px转成rem
options: {
remUnit:75,//设计稿的宽度/10
remPrecision:8,//转换之后的保留小水点后几位
}
}
]
},
还是要注意顺序，这个东西应该放在最先执行。
三、externals
这是官方的解释，通俗一点就是当我们的代码通过import引入一些库的时候，这些库的代码也是会被打包进bundle里面的，这样依赖我们的bundle 就会显得很大，通过上面说的这个配置可以防止将这些库打包进bundle 里面，同时配置一个别名，让我们的代码可以正常的使用外部的库。但是这也需要我们自己准备相应的cdn来加载这些被排除在外的库。
这样做的好处就是bundle 的体积会大大减小，构建速度会很快。但是这样一来我们也就丧失了按需引入的功能，同时也没办法对这些库做treeshaking优化
四、scoremap的使用
在webpack构建完应用之后，如果代码出现了报错，这个时候定位到的是打包编译后的代码，非常不利于调试。这个时候scoremap就可以帮到我们，他可以把源代码打进产物里，方便我们进行调试程序。
接下来我们看看没有scoremap和有scoremap有什么区别
首先是没有scoremap的，
可以看到，点进报错之后是打包之后的代码，非常不利于调试。
接下来我们开启scoremap试试
是不是非常的方便，他的开启方式非常简单，只需要在webpack.config里配置devtool值为一个scoremap类型（webpack提供了很多种scoremap，效果都不一样，可根据自己需要去选择。） 当然scoremap肯定是不希望在生产环境开启的，因为他不仅会加大产物的体积，同时也会暴露出我们的源代码。所以一般只在生产环境开启。
直接在package.json里配置的生产环境启动指令里配置devtool就行了
五、splitChunksPlugin
代码分割，webpack构建过程中重要的优化策略。有了他我们就可以把一些公共代码提取出来，避免了重复打包，并且还可以把这些不经常改变的代码抽离成一个单独的chunks，充分利用浏览器的缓存策略。
https://www.webpackjs.com/plugins/split-chunks-plugin/#root 这是官方文档，下面我们来简单使用一下。
例如我们现在在构建一个vue项目，影响bunlde大小的首当其冲的就是vue.js，这个时候就可以考虑把vue的源码抽离成一个单独chunks。
optimization: {
splitChunks: {
cacheGroups: { //配置分离出来的chunks
commons:{
test: /(vue)/,
name: 'vendors',
chunks: "all"
},
}
}
},
这样配置之后，vue就会被单独构建，不会夹杂在bunlde中。
下面再来看看如何抽离公共代码
optimization: {
splitChunks: {
/**
* 这表明将选择哪些 chunk 进行优化。当提供一个字符串，有效值为 all，async 和 initial。
* 设置为 all 可能特别强大，因为这意味着 chunk 可以在异步和非异步 chunk 之间共享。
*/
// chunks:'all',
// minSize: 3000,//需要处理的chunks的最小字节
// maxSize: 0,//同上，相反
// minChunks:1,//chunks最小被引用次数，超过这个次数就会被处理
minSize: 3000,//只要引用了就会被成单独的chunks
cacheGroups: { //配置分离出来的chunks
commons:{
test: /(vue)/,
name: 'vendors',
chunks: "all"
},
utils:{
name: 'utils',
chunks: "all",
minChunks: 2, //只要引用了两次以上就会被处理
}
}
}
},
我们可以配置引用次数，文件大小，文件引入方式等来告诉webpack，哪些代码要被抽离。 而抽取公共代码，我们主要就是配置minChunks这个属性，只要引用次数超过了这个值就给他抽离出来。下面看看构建结果
六、TreeShaking
这是webpack内置的摇树优化，默认情况下production模式会自动开启，不需要我们手动去设置。他的作用主要就是剔除死代码，没有用的代码，减少包的体积。他只能对esm编写的模块化代码生效，因为他需要依赖esm的静态导入的方式，在编译阶段确定依赖关系，才能去剔除死代码。
七、ScopeHoisting
这也是webpack内置的一个优化策略，在没推出这个策略之前，webpack会给每个导入进来的模块都生成一个闭包函数，例如我们暴露一个a变量，然后再别处引入这个a并且打印他，webpack会生成两个函数，一个函数用来引入a变量，另一个函数用来打印这个a变量。 这样一旦模块多了，代码的体积就会非常庞大，并且会生成很多不必要的作用域，浪费内存。所以webpack推出了ScopeHoisting来优化此问题
优化前
优化后
八、懒加载文件
懒加载也是webpack中一个重要的优化手段，像大家熟知的vue的路由懒加载，其原理就是只加载当前要用到的东西，其他东西等需要用到的时候再去加载。
懒加载其实是利用了import()这个函数，用法其实也很简单，在函数中传入文件路径即可引入，这个方法返回的是一个promise对象，所以我们需要在.then里去使用引入的内容。下面来看一个 小示例
<template>
<div class="content">8888</div>
<button @click="handlerLoad">home</button>
</template>
<script>
export default {
name: "home",
methods:{
handlerLoad(){
import(/* webpackChunkName: "count" */ '/src/js/count').then(count=>{
// 异步加载需要在回调函数中使用引入的东西
console.log(count)
const total = count.sum([1, 2, 3, 4])
console.log(total)
})
}
}
}
</script>
<style scoped>
</style>
上面的代码我们给button绑定了一个点击事件，在这个点击事件中去动态的加载了一个js文件
在页面中点击这个button就可以看到，发送了一个http请求去加载count文件。
