PostCSS并不是一个直接写样式的语言，而是一套基于JavaScript的CSS转换框架。它通过读取配置文件，调用各类插件对原始CSS做解析、转换和生成，从而实现自动加前缀、压缩代码、支持未来语法等目的。很多构建问题其实都出在配置顺序和插件选型上，理清这两点就能少走弯路。
一、PostCSS配置文件的结构与写法
最常见的配置方式是项目根目录下的postcss.config.js。在这个文件里，最核心的字段是plugins。它可以写成对象形式，也可以写成数组形式，两者在加载机制上有细微差别。对象形式适合只需要启用默认配置的插件，数组形式则能在插件后面传参，控制得更细。
下面是一段对象形式的配置示例，autoprefixer和cssnano都使用默认行为：
module.exports = {
plugins: {
autoprefixer: {},
cssnano: {}
}
};
如果你需要对某个插件传参，比如限定autoprefixer只兼容特定浏览器，就要改用数组形式。数组里的每一项既可以是插件函数，也可以是[插件, 参数对象]这样的元组。这种写法在大型项目中更常见，因为不同环境往往需要不同的兼容策略。
module.exports = {
plugins: [
require('autoprefixer')({
overrideBrowserslist: ['last 2 versions', 'ie >= 11']
}),
require('cssnano')({
preset: 'default'
})
]
};
配置文件放置位置的影响
PostCSS会按项目目录向上查找配置文件，如果子目录也有一份，就可能发生配置合并或覆盖。一般建议只放在根目录，避免多个配置互相打架。当使用Vite、Webpack等工具时，它们通常允许在对应loader或插件选项里直接写PostCSS配置，这时可以省略独立文件，但原理相同。
另外要注意，postcss.config.js是CommonJS规范，用module.exports导出。若项目本身是ESM模式，可改用postcss.config.cjs文件名，防止被打包器误判为ES模块导致报错。
二、常用插件的能力对比与选择
面对社区里上百个PostCSS插件，初学者容易一股脑全装，结果构建变慢且产物冗余。实际上日常开发优化里，只要选准几个就能覆盖绝大多数需求。下面用表格列出三款最基础的插件及其职责。
| 插件名称 | 主要作用 | 是否建议默认开启 |
|---|---|---|
| autoprefixer | 根据浏览器兼容列表自动添加厂商前缀 | 是 |
| cssnano | 压缩并优化CSS，删除空白与重复规则 | 生产环境是 |
| stylelint（配合postcss接口） | 静态检查CSS写法，统一代码风格 | 开发环境可选 |
autoprefixer的底层逻辑
autoprefixer并不会盲目给每个属性加-webkit-之类的前缀，而是读取Can I Use数据库，结合你配置的浏览器范围决定要不要加、加哪些。比如你写display: flex，在需要兼容旧版安卓时，它会输出包含display: -webkit-box等老语法的代码。这样既能兼容又不会让文件膨胀得太厉害。
配置浏览器范围时推荐使用overrideBrowserslist字段，而不是已废弃的browsers选项。下面展示一段带兼容范围的写法，注意里面的>符号在JavaScript字符串里不需要转义，但在CSS产物比较时浏览器会正常解析：
module.exports = {
plugins: [
require('autoprefixer')({
overrideBrowserslist: ['> 1%', 'last 3 versions']
})
]
};
cssnano的取舍
cssnano在压缩时会做很多激进优化，例如合并相同选择器、缩短颜色值。虽然在生产环境能显著减小体积，但有时会让调试时的源码映射变复杂。因此建议只在构建生产包时启用，开发服务器里关掉，保证断点样式可读。
如果担心默认预设太狠，可以选用preset: 'lite'只做安全压缩，或者手动传参关闭某些规则。下面代码演示如何只开启合并与去空，不碰其他高级优化：
module.exports = {
plugins: [
require('cssnano')({
preset: ['lite', { discardComments: { removeAll: true } }]
})
]
};
三、组合实践与构建优化思路
把插件按顺序排好，是PostCSS配置里最容易被忽略的细节。插件按数组从前到后执行，如果先压缩再补前缀，某些压缩后的简写可能被前缀插件误判；正确顺序是先让autoprefixer补齐兼容代码，再交给cssnano压缩，这样产物既全又小。
在Webpack里，通常这样串起PostCSS和CSS加载器。注意postcss-loader要放在css-loader之前，保证CSS在转成JS模块前就被处理完：
module.exports = {
module: {
rules: [
{
test: /.css$/,
use: [
'style-loader',
'css-loader',
{
loader: 'postcss-loader',
options: {
postcssOptions: {
plugins: [
require('autoprefixer'),
require('cssnano')
]
}
}
}
]
}
]
}
};
按环境拆分配置
借助process.env.NODE_ENV，我们可以让开发构建跳过压缩、只跑前缀和校验，提升热更新速度；生产构建再开启cssnano。这种拆分在团队协作时尤其有用，每个人本地跑起来都轻快，上线包却又足够精简。
下面示例展示了如何通过环境变量决定插件列表，开发时仅用autoprefixer，生产时追加cssnano：
const isProd = process.env.NODE_ENV === 'production';
const plugins = [require('autoprefixer')];
if (isProd) {
plugins.push(require('cssnano'));
}
module.exports = { plugins };
总体来看，PostCSS的配置并不复杂，难的是弄清每个插件做了什么、以什么顺序做。把握住补前缀、压缩、校验三条主线，再按环境开关，就能搭出顺手且高效的样式处理流程。
PostCSSpostcss_configautoprefixer修改时间：2026-08-09 23:27:48