工具类系统体积失控的根源在于编译期全量生成规则，而非压缩失效；应限制循环范围、启用purgecss裁剪、禁用@extend和全量@import，从源头控制输出。
工具类系统（如 .m-1 到 .m-100）本身就会直接生成等量 CSS 规则，Sass 的 --style=compressed 对它完全无效——它只删空格，不删规则。体积爆炸不是压缩没开好，而是你主动把 100 条规则写进了源码。
为什么循环生成工具类会让 CSS 体积失控
常见错误现象：grep -o "margin:" main.css | wc -l 返回 200+，但项目里只用了不到 10 个间距值；gzip -c main.css | wc -c 显示压缩后仍超 150KB。
- @for 或 @each 每次迭代都生成一条独立规则，Sass 不做去重、不判断是否真实使用
- 哪怕只用
.m-2和.p-4，整个循环仍全量输出 - 嵌套在
@media或&.dark里时，还会乘以媒体查询数或主题数，呈指数级膨胀 - cssnano 无法合并这些规则——它们属于不同选择器，不是重复声明块
改用插值 + purgecss 才是可行路径
别让 Sass 编译期生成所有类，把“生成”交给构建时裁剪环节，才能真正按需保留。
- 用
@for $i from 0 through 8 { .m-#{$i} { margin: #{$i * 0.25}rem; } }这类有限范围插值，而非 1–100 - 确保构建流程中接入
purgecss（或unocss/windi css），并正确配置content字段扫描所有模板、JSX、Vue 文件 - 禁用
@each $key, $val in $map中调用含选择器的@mixin，它会把整块样式复制 N 遍 - 若必须用动态类名（如
.bg-[#ff0000]），改用postcss插件处理，而非 Sass 编译期展开
@extend 和 @import 是隐藏的体积放大器
工具类系统常和 @extend 或全量 @import 混用，进一步加剧冗余。
立即学习“前端免费学习笔记（深入）”；
- 禁止
%spacing-base这类占位符被多个工具类@extend——它不会共享声明，只会复制多份margin: ... - 不要
@import "bootstrap/scss/utilities"，改用@use "bootstrap/scss/utilities/_spacing" as space按需加载 - 检查第三方 UI 库是否悄悄注入了整套工具类（如 Element Plus 的
el-space默认带 20+ 间距类），考虑用:global()隔离或替换为原子类
真正有效的体积控制点不在压缩，而在源头约束
压缩工具对工具类系统几乎无能为力：cssnano 合并不了不同选择器的相同声明，--style=compressed 只是把 100 行压成 1 行，字节数几乎不变。关键动作是限制生成上限、交由 purgecss 裁剪、切断 @extend 和全量 @import 的链路。最易被忽略的是——你写的每一条 @for，都在编译时铁定变成对应数量的 CSS 规则，没有例外。
