现代CSS架构中Sass与PostCSS结合的优势

先说一个核心结论：Sass 与 PostCSS 从来不是互相取代的竞争关系。在现代前端 CSS 架构中，它们是一对分工明确、协同工作的上下游搭档——Sass 负责“将逻辑写清楚”，PostCSS 负责“让输出更可靠”。一旦搞反两者的协作顺序，整个 CSS 构建流程就会直接报错甚至崩溃。

Sass 编译必须在 PostCSS 处理之前

Sass 的核心职责，是将包含变量、嵌套、@mixin、@function 等高级语法的样式文件，可靠地编译为标准 CSS。它无需理会浏览器兼容性、代码压缩或自动加前缀等工作。如果跳过这一步，直接将 .scss 文件交给 PostCSS，解析器将直接报错——因为 PostCSS 只认合法 CSS，根本不认识 $color 或 @if 这类 SCSS 关键字。 因此，CSS 构建流程的编排有一个关键注意事项： - 在 Webpack 中，sass-loader 必须排在 postcss-loader 之前 - 如果使用 Vite，默认情况下 vite-plugin-sass 的执行顺序在 postcss 阶段之前，通常不会出现问题 - 若构建时报错提示 Unknown word 或 Unexpected token "$"，多半是因为 Sass 未被首先编译，而直接让 PostCSS 处理了未转换的 SCSS 源码

autoprefixer 无法替代 Sass 的结构化能力

autoprefixer 是 PostCSS 生态中最常用的插件之一，但它只完成一件事：查询 Can I Use 数据库，再根据你的目标配置，自动添加 -webkit-、-ms- 等浏览器前缀。除此之外，它不具备任何样式组织或抽象能力。 它无法： - 定义一个全局主题色变量，例如 $primary: #3498db - 封装按钮通用样式逻辑，例如 @mixin btn-base - 基于断点生成响应式栅格，例如用 @for 循环生成 .col-1 到 .col-12 这些结构化的组织能力必须依赖 Sass 在编译阶段完成。如果强行用纯 PostCSS 配合一堆插件去模拟这些功能，要么代码变得又长又啰嗦，要么维护性直接崩溃。

cssnano 压缩对未编译的 Sass 无效

cssnano 插件的工作对象是编译后的标准 CSS AST（抽象语法树），它负责合并属性、去除多余空白、缩写颜色值等优化。如果直接将 .scss 源文件传给 cssnano，同样会触发报错退出。 正确的处理链路应该是： input.scss → dart-sass → output.css → postcss（包含 cssnano）→ dist.css 实际开发中有一个常见陷阱：在 Webpack 配置 loader 时，如果把 postcss-loader 放在了 sass-loader 前面，压缩环节拿到的输入依然是 SCSS 语法，构建会直接失败。而且 cssnano 压缩已编译的 CSS 效率很高，强行让它处理未编译的源文件，既无法工作也得不偿失。

sourceMap 调试链容易在中间环节断裂

开发时，大家都习惯在浏览器 DevTools 中点击样式，直接跳回源文件 .scss 进行修改。这种流畅体验高度依赖一条完整的 sourceMap 链路：从 .scss 到 .css 再到 .min.css。但许多项目的配置，常常会无意中切断这条链。 这里有几个容易出错的地方： - sass-loader 默认会生成 sourceMap，但如果 postcss-loader 那边没有配置 sourceMap: true，后续步骤就会丢失映射关系 - cssnano 默认会丢弃 sourceMap，需要显式配置，例如 preset: ['default', { discardComments: { removeAll: true } }]，同时确保 sourceMap 能向下传递 - 如果使用 postcss-sass 这类融合工具，需要检查它能否透传原始 .scss 文件的位置信息。Dart-Sass 通常支持，而 Node-Sass 已经废弃，不建议继续使用 说到底，真正让人头疼的往往不是语法错误，而是那种“样式明明生效，但改了 SCSS 文件却完全没反应”的情况。十有八九，都是某个环节的 sourceMap 配置或 watch 配置漏掉了。