PostCSS 本身不处理 CSS 转换，仅提供解析与处理框架，所有功能依赖插件；高频插件包括 postcss-preset-env（支持新特性并加前缀）、autoprefixer（仅加前缀）、postcss-nested（嵌套语法）、postcss-import（@import 合并，须置首）；插件顺序至关重要：postcss-import 必须第一，postcss-preset-env 应在 autoprefixer 前；验证方式有 --verbose 查看 AST 变化或引入 postcss-reporter 输出警告。
PostCSS 本身不处理任何 CSS 转换逻辑，它只是提供一个解析器和处理器框架——所有功能都依赖插件。没装对插件，postcss 命令跑出来就是原样输出。
哪些插件解决最常见需求
日常开发中高频使用的功能基本靠这几个插件实现：
-
postcss-preset-env：替代autoprefixer+postcss-custom-properties等一堆插件，自动启用 Stage 2+ 的 CSS 新特性（比如color-mix()、accent-color），并按目标浏览器加前缀 -
autoprefixer：如果只要前缀补全，这个更轻量；但注意它不处理自定义属性、嵌套等语法扩展 -
postcss-nested：支持 SASS 风格的嵌套写法（&、@at-root），但和postcss-nesting（原生@nest）不兼容，别混用 -
postcss-import：在@import阶段做合并（类似 Webpack 的css-loader），必须放在插件数组最前面，否则其他插件看不到被导入的内容
插件加载顺序直接影响结果
PostCSS 按数组顺序依次调用插件，顺序错会导致语法解析失败或规则被跳过。典型踩坑点：
-
postcss-import必须排第一，否则postcss-nested看不到嵌套在@import文件里的规则 -
postcss-preset-env应该在autoprefixer之前，否则新语法（如hsl(from ...)）还没转成兼容格式就被前缀插件忽略 - 自定义插件若依赖 AST 修改（比如重写选择器），要放在语法扩展类插件（如
postcss-nested）之后、压缩类插件（如cssnano）之前
如何验证插件是否生效
别只看最终 CSS 输出，容易漏掉中间环节问题。推荐两种快速验证方式：
立即学习“前端免费学习笔记（深入）”；
- 用
postcss-cli加--verbose参数运行：postcss input.css -u postcss-preset-env --verbose
它会打印每一步插件处理前后的 AST 节点数变化 - 在配置里临时加一个调试插件，比如：
module.exports = { plugins: [ require('postcss-reporter')({ clearReportedMessages: true }) ] }它会把警告/错误直接打到控制台，比如 “Unknown word” 通常意味着某个插件没加载或顺序错了 - 检查
package.json中插件版本：postcss-preset-env@9+要求postcss@8.4+，低版本会静默失效
插件不是装得越多越好，每个都增加解析耗时；真正卡住的往往是顺序和版本对不上，而不是功能缺位。
