在 grunt-postcss 链式调用 autoprefixer 与 cssnano 的顺序原则 - 问题详情 - 创脉思

解读

面试官抛出此题，表面问“谁先谁后”，实则考察三点：

对 PostCSS 插件执行顺序与 AST 完整性 的理解；
对 autoprefixer（加前缀）与 cssnano（去冗余、压缩）各自职责边界与副作用 的掌握；
在真实 CI/CD 流程里，如何保证样式兼容性与体积优化兼得 的工程经验。
国内大厂（阿里、腾讯、字节）的 Lint 规范与性能红线中，顺序错误会被视为“低级但致命”的构建事故，因此必须给出可落地的原则与验证方法。

PostCSS 链式执行模型：同一 AST 顺序遍历，插件对 AST 的修改会直接影响后续插件输入。
autoprefixer：依据 caniuse 数据库与 browserslist 规则，添加 / 补全 / 删除前缀，依赖完整且未压缩的声明。
cssnano：包含 autoprefixer 移除重复前缀、合并相同规则、丢弃过时前缀、压缩 calc()、颜色值、网格声明等 优化策略；若先执行 cssnano，可能提前删除仍需兼容的旧前缀，导致线上低版本浏览器样式失效。
grunt-postcss 配置字段 processors 为纯数组顺序执行，无内部依赖解析，顺序完全由开发者控制。
国内常见 browserslist 示例：> 1%, last 2 versions, Android >= 4.4, iOS >= 9，需与 autoprefixer 的 flexbox、grid 前缀策略 对齐。
验证手段：
1. 使用 npx browserslist 打印目标浏览器；
2. 在 postcss-reporter 中开启 throwError:true，捕捉缺失前缀；
3. 在 cssnano 中关闭 autoprefixer: false 避免二次删除；
4. 通过 grunt-contrib-cssmin 与 gzip-size-cli 双重确认压缩率。

必须 autoprefixer → cssnano，理由如下：

autoprefixer 需要完整且语义清晰的 CSS 规则来判断哪些声明需要前缀；若 cssnano 先执行，其合并、删除过时前缀的操作会破坏 autoprefixer 的输入，导致旧版 WebKit 或 IE 缺失关键兼容前缀。
cssnano 的 colormin、calc 等优化对前缀无依赖，但自带 autoprefixer 子插件（默认关闭），若顺序颠倒且误开启，会出现**“刚加完就被删”** 的竞态，造成构建缓存失效、输出体积异常。
国内移动端的 UC 浏览器、微信 X5 内核 仍在使用 2016 版 Chromium，autoprefixer 需保留 -webkit- 前缀；若 cssnano 先执行，可能误删，线上白屏或布局错乱将直接触发 P0 故障。
工程化验证：在 Gruntfile 中先写 require('autoprefixer')，再写 require('cssnano')，执行 grunt postcss --verbose，观察 “prefixed in” 与 “optimized” 两条日志的先后顺序；随后用 npx postcss-cli --use autoprefixer --use cssnano 对比 --use cssnano --use autoprefixer 的输出 diff，后者会丢失约 3% 的前缀规则。

若项目使用 CSS Modules 或 Scoped CSS，autoprefixer 需在 scope 编译之后、cssnano 之前插入，避免局部选择器被意外合并。
在 微前端多仓库 场景下，可把 autoprefixer 抽成独立任务，生成 .browserslistrc 统一托管到 @company/browserslist-config 包，cssnano 放在各仓库私有流程，实现“兼容性中心化 + 压缩去中心化”。
当需要 tree-shaking 样式（如使用 purgecss）时，推荐顺序：
postcss-import → purgecss → autoprefixer → cssnano，任何一步顺序颠倒都会导致体积或兼容性回退。
国内云构建（阿里云 Flow、腾讯云 CODING）默认使用 npm 国内镜像，需锁定 autoprefixer 与 cssnano 的次版本号，避免 caniuse-lite 数据更新导致前缀策略突变；可在 Gruntfile 中加入 process.env.BROWSERSLIST_IGNORE_OLD_DATA=true 抑制旧数据警告，保证 CI 日志干净。