sass 的 --style=compressed 仅做基础空格移除，不合并选择器、删无效声明或处理重复属性；真正压缩需 postcss（如 cssnano）介入构建流程，且须显式桥接，不可依赖 sass 自身。
用 sass 命令行直接压缩 CSS 输出
默认情况下 sass 编译出来的 CSS 是未压缩的，哪怕加了 --style=compressed，它也只做基础空格移除，不合并选择器、不删无效声明、不处理重复属性——这不是真正意义上的“性能优化”。真正的压缩得靠 PostCSS 或构建工具链配合。
实操建议：
-
sass --style=compressed input.scss output.css只能做最简压缩，适合单文件快速验证，别指望它替代cssnano - 若项目已用 Webpack/Vite，优先在
css-loader或postcss阶段配置cssnano，sass只负责变量/嵌套等语法转换 - 注意
--style=compressed会禁用 source map，调试时得切回expanded并手动配--source-map
Sass 编译后无法启用 cssnano 的常见卡点
很多人把 sass 当成“编译+压缩”一体化工具，结果发现 CSS 体积没变小，其实是 pipeline 断了。Sass 本身不调用 PostCSS 插件，必须显式桥接。
常见错误现象：
- 在
sass命令里加--load-path node_modules想引入cssnano—— 不生效，sass根本不识别该插件 - Vite 项目里改了
vite.config.ts的css.postcss，但 Sass 文件没走 PostCSS（因为 Vite 默认对.scss启用的是sass+ 内置 CSS 处理，PostCSS 配置需显式启用） - Webpack 中用了
sass-loader，但没在options.sassOptions外再配postcss-loader，导致压缩逻辑被跳过
sass 和 dart-sass 对压缩行为的影响
现在 npm 安装的 sass 包就是 Dart Sass，但旧项目可能还残留 node-sass（已废弃）。二者压缩能力一致，但兼容性差异明显。
关键区别：
-
node-sass不支持--style=compressed的某些新特性（如嵌套媒体查询压缩），且 Node.js 16+ 已无法安装 -
dart-sass的--style=compressed会自动移除注释、合并长宽声明（如margin-top: 10px; margin-right: 5px;→margin: 10px 5px 0 0;），但不会重写calc()或降级var(--x) - 若你依赖 CSS 自定义属性或现代函数，别指望
sass压缩阶段做 polyfill，那是postcss-preset-env的事
自动化压缩必须绕开的陷阱：Source Map 错位与缓存污染
压缩和 Source Map 一起上，最容易出错的是映射关系断裂——浏览器里点开开发者工具，看到的行号指向原始 SCSS 文件的某一行，但实际编译后 CSS 被压成一行，点进去全是空白。
实操要点：
- 不要同时用
sass --source-map --style=compressed：Dart Sass 在 compressed 模式下生成的 Source Map 准确性低，尤其含 @use/@forward 时 - 推荐方案：先用
--style=expanded --source-map编译出带完整映射的 CSS，再交给cssnano单独压缩（它支持从输入 CSS 的 Source Map 重建映射） - CI/CD 中记得清
node_modules/.cache/sass，Dart Sass 的缓存机制有时会复用旧编译结果，导致压缩没生效却显示“已更新”
真正难的不是加个 flag，而是让压缩、映射、缓存三者在不同工具间对齐。少一个环节，就容易在上线后发现样式错乱却查不到源头。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
