首先，我们来了解下它们的作用：
postcss-loader：它是用来自动补全浏览器前缀的，怎么理解呢？
比如说，我们平常去写一些 CSS3 的样式，例如：
#div {
transform: rotate(30deg);
}其实这样写，它并不全面，为什么呢，因为如果真的写全的话，它应该是这样的：
#div {
-webkit-transform: rotate(30deg);
-moz-transform: rotate(30deg);
-ms-transform: rotate(30deg);
-o-transform: rotate(30deg);
transform: rotate(30deg);
}但是如果我们这样写的话，就会有两个问题：
1，我们平常项目中的样式太多了，如果每一个样式都要这么写的话，不仅麻烦，文件体积也会大很多，并且后续也不好维护。
2，有些样式的前缀，我们是不确定，到底要不要加的。
比如说 -o-transform 其实早就已经不用再加 -o- 了，这是因为 Opera 浏览器的内核早就已经换成 webkit 了。
而 -moz-transform 也不用再加 -moz- 了，因为现在主流的火狐浏览器早就已经开始认标准写法 transform，所以 -moz- 也已经没用了。
所以这时候，我们就需要一个帮手 autoprefixer：它里面内置了一个浏览器的兼容表，简单来说就是一个很大很全的表格，它会告诉我们哪个东西是哪个浏览器认识的，这个浏览器的市场占有率是多少等等。
autoprefixer 它会根据市场占有率的高低来决定我要不要加这个前缀，因为如果每个都加的话，比如一个特性，全球就只有几十个人在用，都加上去，是没有意义的。所以它默认是 5% 原则，也就是说如果某一个特性，它的使用人群占比在 5% 以上，它就会把这个选项给加上。
因此我们就知道了：
postcss-loader 是专门用来加浏览器前缀的，但是它自己也就只能加个前缀而已，因为它自己不知道哪个该加，哪个不该加。
所以我们需要 autoprefixer 来告诉它，哪个加，哪个不加。
同时，我们还要知道一点：autoprefixer 不仅仅可以和 postcss-loader 配合使用，任何跟浏览器的某种兼容特性相关的事，都可以找 autoprefixer。
那么接下来，我们就来看下，它们应该怎么写：
我们在之前项目的基础上，先下载：npm install postcss-loader autoprefixer -D
接下来，我们在 src/css/main.css 里面加个样式，鼠标移入转90度：
然后我们就需要把 postcss-loader 给加上：
postcss-loader 为什么要加在 css-loader 后面呢？
说白了，就是你在处理 css 之前，让我（postcss-loader）先来处理一下，我先把该加的前缀都加上了之后，然后再给你去处理。
那么现在我们先不加 autoprefixer，直接编译了，看看效果：
可以看到，直接就给报错了，其实就一句话：找不到 postcss 的 config 文件。
其实 postcss 需要一个配置，以便于它知道，到底要按照什么标准去做。
那么我们就来创建一个 postcss.config.js 文件，它里面也是输出一个 json，和 webpack.config.js 一样：
它里面主要就是一个 plugins，既然后面带 s，那就说明可以有很多 plugin，所以它对应的值就是个数组了。
那么在这里，我们就需要 autoprefixer 了。
加完了配置，我们重新编译下
这时候就成功了，我们打开浏览器，可以看到，transform 和 transition 都有 -webkit- 前缀了：
加了 -webkit- 前缀，也就说明，现在还是有一些老版本的 Chrome 浏览器存在。
虽然编译成功了，但是现在有个问题存在：我们单独的创建一个 postcss.config.js 文件是不是太麻烦了？
其实我们的 loader 还有另一种写法：
use 里面我们现在写的都是字符串，其实这是一个简写。它完整的写法是这样的：
这两种写法其实是等同的，我们可以用这种 json 的格式，然后重新编译下看看效果：
可以看到，编译成功，刷新浏览器，效果也都是一样的。
那么 json 格式里面，除了 loader 这个必填项之外，还可以加一个 options 选项，我们可以加一些自己需要的选项。
在这里我们主要就需要一个 plugins：
相信看到这里，大家已经知道要写啥了，没错，就是和 postcss.config.js 里面的一模一样。
我们的目的不就是为了，不再单独的去创建一个 config 文件吗。
我们可以把它们放到一起去实现：
然后，我们删掉 postcss.config.js 文件，并且编译：
同时，浏览器上面显示也都是正常的：
所以，我们不用再去单独的创建一个 config 文件了，而是可以把它放到 webpack 的 config 里面来，这样就会方便很多。
因为我们现在用的 postcss，autoprefixer 都是默认配置，那如果我们的项目有定制的需求，怎么做呢？
首先我们先来看看它的支持情况怎么样：npx autoprefixer --info
npx 是什么意思呢？npx 它会首先到我们项目中的 node_modules 里面去找，如果没有的话，再去全局找。
其实 npx 和 npm 是差不多的，只不过 npx 是专门用来执行一个包的，而不是用来执行 node.js 本身的那些包管理之类。
我们可以看到，有很长的一列东西展示出来了，这些就是跟 autoprefixer 相关的一些信息，比如最上面的 Browsers 就是浏览器的支持情况，At-Rules 就是支持的规则等等。
我们可以看到：transform: webkit。意思就是说，transform 是需要加一个 webkit 前缀的。
那么具体怎么配置呢？
其实还是单独的创建一个文件 .browserslistrc
它主要就是对 browserslist 做一个配置，用来告诉你，编译的过程中，我要遵循什么样的规范。
last 5 version 的意思就是：我会支持浏览器的最后 5 个版本。
> 1% 的意思就是：超过 1% 的用户，在使用某一个特性，我就来支持它。
这里面的配置都是可以根据自己的需求来定义的，并且可以写很多配置，一行一个，按照它的规则写就行了。
然后我们再重新编译：那么它就会在编译的过程中，自动的来找这个文件，并且会采用我们的这个配置文件。
然后我们就可以看到，和之前编译的结果就会有点区别了：它多出了 -ms- 和 -o- 前缀了，因为我支持的是浏览器的最后 5 个版本，以及市场占有率超过 1%，相当于我扩展了它所支持的范围。
那么这样单独的创建一个配置文件也是不太方便的，能不能和 postcss 一样，集成在一起呢？
答案是肯定的，那么放到哪里去呢？
这次我们就不放到 webpack.config.js 里面去了，我们会放到 package.json 里面：
然后我们删掉 .browserslistrc，再重新编译：
可以看到，配置还是起作用的。
那么这个具体怎么去配置，就要看我们项目中的需求如何了，如果你说需要多兼容几个版本，那么OK，但是你需要知道，它的缺点就是，编译之后的文件体积会比较大。
