@extend在BEM中反而增大CSS体积，因其静态合并选择器导致重复规则和组合爆炸，阻碍PurgeCSS识别；应改用@mixin封装样式，保持类名独立、语义清晰、压缩友好。
为什么@extend在BEM项目里反而让CSS更大
@extend 和 BEM 天然冲突：BEM 要求每个类名语义独立、可预测，而 @extend 的本质是静态选择器合并。当你写 .card__title {@extend %text-emphasis;}，Sass 会把所有匹配 %text-emphasis 的声明“复制”进该选择器；同样地，.list__item {@extend %text-emphasis;} 又会再复制一遍——哪怕样式完全相同，最终 CSS 里仍是两条独立规则，而不是共享声明。
更糟的是，如果 %text-emphasis 含 &:hover 或嵌套上下文（如 .card &），@extend 会触发组合爆炸：一条占位符可能产出十几条变体规则。PurgeCSS 看到的是两个不同选择器，不敢删任何一条，体积和维护成本双双上涨。
- 别用
@extend优化 BEM 组件内部样式复用 - 禁止跨文件
@extend，比如card.scss去继承layout.scss里的占位符 - 占位符内禁用
&:hover、@media、.parent &等上下文敏感写法
什么时候@mixin比@extend更可控
@mixin 是“复制声明”，不是“合并选择器”。它不生成新选择器，只展开样式块，因此调用点清晰、工具友好、压缩率高。尤其适合 BEM 场景下保持单类名结构。
比如封装文字强调逻辑：@mixin text-emphasis 定义字体粗细、颜色、行高，然后在 .card__title 和 .list__item 中分别 @include text-emphasis。最终 CSS 仍是两个独立类名，但样式内容一致，gzip 和 PurgeCSS 都能高效处理。
- 需要传参（如颜色、尺寸）时，
@mixin天然支持，@extend完全做不到 - 涉及伪类（
&:hover）、媒体查询（@media）或 BEM 子元素（&__header）时，@mixin的&解析更可靠 - 避免在
@each循环中@include含选择器的 mixin —— 改用插值生成原子类，交由 PurgeCSS 裁剪
@extend 的唯一安全使用场景
@extend 并非完全不能用，但必须卡死边界：只用于无状态、无上下文、可直接加到 HTML 的原子行为，且定义与调用严格隔离。
例如 %sr-only（视觉隐藏）、%clearfix（清除浮动），它们不依赖父级、不含伪类、不参与响应式逻辑。这类占位符被多个组件引用时，Sass 确实能归并为一条规则，真正减少体积。
- 只继承以
%开头的占位符，绝不用真实类名（如.btn）——防止无意义类名泄露到输出 CSS - 占位符定义必须在同一个文件或明确受控的模块内，禁止跨组件
@extend - 必须用
@use显式导入，比如@use "base"; @extend base.%sr-only;，避免@import引发的隐式拼接和重复注入
真正影响体积的不是格式，而是编译逻辑
sassOptions.outputStyle: 'compressed' 只删空格换行注释，不解决语义冗余。真正撑大 CSS 的，是 @mixin 无节制展开、@extend 触发的选择器爆炸、以及跨文件重复定义。
比如 flex-center mixin 在 23 个组件里各自 @include，就会产生 23 次一模一样的 display: flex; justify-content: center; —— 这不是格式问题，是编译策略问题。
- 纯计算型工具 mixin（如
px2rem()）抽到tools/目录，用@use "tools/functions" as fn调用函数而非 mixin - 视觉型样式（间距、圆角、颜色）优先用 CSS 自定义属性驱动：
--space-sm: 0.5rem;+ 单一类名，声明只存一份 - PurgeCSS 必须放在 Sass 编译之后、CSS 压缩之前，它只能处理已生成的 CSS，无法识别 Sass 源码级重复
实际项目中最容易被忽略的一点：BEM 的价值不在“写得少”，而在“删得准”。@extend 让 PurgeCSS 失去判断依据，@mixin 则让每个类名的使用路径清晰可见——这才是现代构建链路里真正可控的体积优化起点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
