别在BEM组件里用@extend——它会增大CSS体积、使PurgeCSS失效、增加DevTools调试难度；因其本质是静态复制规则而非复用，导致重复代码和选择器爆炸，仅极少数无上下文占位符可谨慎使用，推荐改用@mixin。
别在BEM组件里用 @extend 扩展基础样式——它会让CSS体积变大、PurgeCSS失效、DevTools调试困难。
为什么 @extend 和 BEM 一起用会撑大 CSS？
@extend 的本质是静态选择器合并，不是“复用样式”，而是“复制规则”。当你写 .card__title {@extend %text-emphasis;}，Sass 会把所有 %text-emphasis 的声明块完整塞进 .card__title；如果 .list__item 也 @extend %text-emphasis，同样的声明块会被再塞一遍。结果是两段完全相同的 CSS 块，无法被 PurgeCSS 或 gzip 合并识别。
更糟的是：如果 %text-emphasis 里含 &:hover 或嵌套上下文（比如 .card &），@extend 会触发组合爆炸——一个占位符可能生成十几条不同选择器的规则。
- 编译后 CSS 体积不降反升，尤其在多组件复用同一占位符时
- 工具看到的是
.card__title和.list__item两个独立类名，不敢删其中任意一个 - JS 层（如
clsx）无法推断哪些类被真正调用，tree-shaking 失效
哪些场景下 @extend 还能勉强用？
仅限极少数无语义、纯功能、零上下文的占位符，且必须满足三个硬条件：
立即学习“前端免费学习笔记（深入）”；
- 目标必须是
%placeholder，绝不能是真实类名（如.btn），否则会意外输出冗余类 - 占位符定义必须和引用在同一个文件，或明确标记为 “public extendables” 的受控模块（禁止跨 components → layout 引用）
- 占位符内部不能含任何
&:hover、@media、.parent &等会触发选择器膨胀的语法
典型可用例子：%sr-only、%clearfix、%reset-margin —— 它们只做一件事、无状态、无响应式分支。
替代方案：用 @mixin 封装 BEM 组件样式
这才是真正轻量、可维护、压缩友好的写法。样式逻辑集中定义，各组件显式调用，最终 CSS 仍保持单类名结构，PurgeCSS 能准确识别使用痕迹。
示例：
// _mixins.scss
@mixin text-emphasis($weight: 600) {
font-weight: $weight;
color: var(--text-primary);
line-height: 1.4;
}
// card.scss
.card__title {
@include text-emphasis;
font-size: 1.25rem;
}
// list.scss
.list__item {
@include text-emphasis(500);
font-size: 1rem;
}
优势很明显：
-
@mixin只复制声明，不复制选择器，输出仍是干净的.card__title和.list__item - 支持传参（颜色、尺寸、断点），
@extend完全做不到 - 所有调用点清晰可见，HTML class 列表与 SCSS 调用一一对应
BEM 元素/修饰符命名必须用 @at-root 提级
哪怕你真要用 @extend，也别在嵌套块里写 &__title——它会编译成 .card .card__title（带空格的后代选择器），违背 BEM 扁平化原则。
唯一安全写法是跳出嵌套：
.card {
@at-root #{&}__header {
@extend %flex-center;
}
@at-root #{&}--loading {
opacity: 0.7;
}
}
这样输出才是真正的 .card__header 和 .card--loading。但注意：这种写法只是“语法正确”，不代表推荐使用——它没解决 @extend 本身带来的体积和维护问题。
最常被忽略的一点：BEM 的价值不在“少写几个字符”，而在“删得准”。一旦引入 @extend，就等于主动放弃构建阶段的自动化清理能力。体积问题不会在开发时暴露，而会在上线后悄悄拖慢首屏加载。
