Sass与PostCSS结合：现代CSS架构最佳实践

先说一个核心判断：Sass 和 PostCSS 从来就不是你死我活的替代关系。它们在现代CSS架构里，是一对明确分工的上下游搭档——一个负责“写得清楚”，一个负责“发得靠谱”。这俩的协作顺序一旦搞反，构建流程直接翻车。

构建流程中的Sass与PostCSS协作顺序

Sass 编译必须在 PostCSS 处理之前

Sass 的核心工作，是把那些写着变量、嵌套、@mixin、@function 的高级语法，老老实实编译成标准的CSS。它不管什么浏览器兼容性，也不做压缩和加前缀。这一步如果跳过去，直接把 .scss 文件喂给 PostCSS，那 PostCSS 解析器就会直接懵掉——因为它只认合法的CSS，根本不认识 $color 或者 @if 这些SCSS关键字。 所以，构建流程的编排上有一点要注意： - 在Webpack里，sass-loader 必须排在 postcss-loader 前面 - 如果用Vite，默认情况下 vite-plugin-sass 的执行顺序是在 postcss 阶段之前的，一般没问题 - 如果构建时报错说 Unknown word 或者 Unexpected token "$"，那八成就是Sass没先编译，直接让PostCSS去处理了

PostCSS工具与Sass的结构能力差异

autoprefixer 不能替代 Sass 的结构能力

autoprefixer 是 PostCSS 生态里最常用的插件，但它只干一件事：去查CanIUse的数据库，然后按照你的配置，老老实实补上 -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配置给漏掉了。