提取公共类名可能增大css体积，因@extend跨模块时生成冗余组合选择器，如.header .text-center等，比单独声明更大；应优先用css自定义属性+单一声明源替代。
为什么提取公共类名反而可能增大CSS体积
很多人以为把 .text-center、.mt-2 这类工具类抽成Sass mixin或占位符（%utility）就能减小最终CSS，结果压缩后文件更大了。根本原因是：Sass的@extend在多处复用时会做“选择器合并”，但一旦跨模块或存在复杂嵌套，它会生成冗余的组合选择器，比如 .header .text-center, .sidebar .text-center, .modal .text-center —— 这比单独写三行 .text-center { ... } 还大。
实操建议：
- 只对「完全静态、无上下文依赖」的纯视觉类（如
.sr-only、.visually-hidden）用%placeholder+@extend - 避免对带状态（
.btn:hover）、响应式（.md\:flex）或依赖父级（.card > .title）的规则使用@extend - 用
sass --no-source-map --style=compressed配合cssnano二次压缩，否则@extend产生的冗余不会被清理
Sass中真正能压体积的提取方式
不是靠 @extend，而是靠「CSS自定义属性 + 单一声明源」。把颜色、间距、圆角这些值定义在 _variables.scss 里，再通过 var(--spacing-sm) 在CSS中复用，这样即使多个组件用到 margin: var(--spacing-sm)，生成的CSS也只有一份声明，且支持运行时主题切换。
实操建议：
- 变量命名统一前缀，如
--color-primary、--space-md，避免和第三方库冲突 - 禁止在
@keyframes或@media内部直接引用 Sass 变量（它们无法被 CSS 自定义属性替代），该场景仍用原生 Sass 变量 - 构建时用 PostCSS 插件
postcss-custom-properties回退不支持 CSS 变量的旧浏览器，别指望 Sass 编译期解决兼容性
如何验证提取是否真有效果
不能只看 .scss 文件行数变少了，要看最终输出的 .css 字节数，以及浏览器实际加载的样式表解析开销。常见错误是本地开发用未压缩的CSS调试，上线后才发现gzip后体积没降反升。
实操建议：
- 用
npx sass --no-source-map --style=compressed src/main.scss > dist/main.min.css生成真实上线包 - 对比前后用
gzip -c dist/main.min.css | wc -c查看压缩后体积 - 打开 Chrome DevTools → Network → 找到CSS请求 → 看 “Transfer Size” 和 “Resource Size”，如果后者明显变大，说明提取引入了冗余规则
- 检查
main.min.css中是否存在大量重复的margin: 0.5rem—— 如果有，说明你误把本该用CSS变量的地方写成了Sass变量内联
大型项目里最常被忽略的Sass性能点
不是语法怎么写，而是 @import 和 @use 的路径组织。一个 @import "base/typography" 看似简单，但如果这个文件里又 @import "utils/breakpoints"，而另一个模块也导入了同样的 breakpoints，Sass 3.x 之前会重复编译两次——变量重定义、mixin重复展开、甚至生成两套相同的CSS规则。
实操建议：
- 强制升级到 Sass 4+，全面改用
@use，它天然去重，且作用域隔离 - 所有共享模块（如
_variables.scss、_mixins.scss）必须只被@use一次，放在根文件（如index.scss）里，其他文件一律不@use公共模块 - 禁用
@import，哪怕只是临时兼容老代码 —— 它的全局污染会让体积优化前功尽弃
真正卡住体积优化的，往往不是要不要提取，而是提取之后有没有切断重复编译链路。路径依赖比代码逻辑更难排查，出问题时先翻 sass --watch 的编译日志，看同一个文件是否被列出了多次。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
