sass --style=compressed仅删空格、换行和注释，不合并选择器、不剔除未用规则、不简化calc()或颜色值，故体积几乎不变；真正减体积需PostCSS（如cssnano）介入，且源码结构（如滥用@extend、深层嵌套）才是体积膨胀主因。
为什么 sass --style=compressed 压缩后体积几乎没变？
因为 sass --style=compressed 只删空格、换行和注释，不合并重复规则，不剔除未用选择器，也不简化 calc() 或颜色值（比如 #ff0000 不会变成 #f00）。实测 gzip 后体积通常只降不到 3%，而一个滥用的 @extend 或 5 层嵌套就能让原始 CSS 翻倍。
常见错误现象：sass --style=compressed input.scss output.css 执行完，output.css 和未压缩版大小几乎一样——这不是 bug，是它本来就不干这事。
-
--style=compressed是格式整理工具，不是压缩引擎 - 真正减体积必须靠 PostCSS 阶段的
cssnano（比如mergeLonghand、normalizeWhitespace） - Sass 和 PostCSS 是两个独立阶段，命令里加
--load-path node_modules对cssnano完全无效
哪些 Sass 写法会让输出体积“爆炸式增长”？
体积问题从来不在压缩参数，而在源码结构。运行 grep -o "\.btn" main.css | wc -l 或 grep -o "margin:" main.css | wc -l，如果数字异常高（比如几百上千），大概率是以下写法导致：
-
@extend %button-base被多个上下文调用，生成.header .btn、.modal .btn、.sidebar .btn这类重复前缀的选择器 - 嵌套超过 4 层，例如
.card { .list { .item { &:hover { ... } } } }，每层都复制父选择器 -
@import全量引入大文件（如整个 Bootstrap Sass），哪怕只用了一个px2rem()函数 - 循环生成工具类：
@for $i from 1 through 100 { .m-#{$i} { margin: #{$i}px; } }直接产出 100 条规则
Webpack/Vite 中 Sass 输出没走 PostCSS 怎么办？
很多项目以为配了 postcss.config.js 就万事大吉，结果 Sass 文件根本没经过 PostCSS 处理——Vite 默认对 .scss 用的是内置 Sass 编译链，Webpack 的 sass-loader 也不自动桥接 PostCSS。
立即学习“前端免费学习笔记（深入）”；
- Vite：必须在
vite.config.ts中显式启用css.postcss并确保preprocess阶段也走 PostCSS（例如用postcss-scss解析器） - Webpack：不能只配
sass-loader，得在module.rules里把css-loader和postcss-loader接在后面，顺序是sass-loader → css-loader → postcss-loader - 别信 loader 默认值——
sassOptions.outputStyle必须显式设为'expanded'（不是compressed），否则cssnano无法正确解析嵌套和自定义属性
上线构建时容易漏掉的关键开关
--no-source-map 和 --style=compressed 必须成对使用，但开发时绝对不能开——否则调试失效，@debug 和 @warn 也会被静默丢弃。
-
--no-source-map必须显式加：sourceMap 默认可能开启，会在 CSS 末尾追加 base64 编码的映射，轻松多出 100KB+ -
--style=compressed在上线时加：避免后续 PostCSS 工具因解析expanded格式产生额外开销 - 命令行示例：
npx sass src/main.scss dist/main.css --no-source-map --style=compressed - 真正有效的压缩链是：
Sass（expanded）→ PostCSS（autoprefixer + cssnano）→ 最终 min.css，少任何一环都白忙
最容易被忽略的是：Sass 输出阶段没控制好源码结构，后面所有压缩都是徒劳。体积问题不在“怎么压”，而在“写了什么”。
