@extend导致选择器爆炸式增长，因其编译时仅机械拼接完整路径而非语义复用；嵌套越深、引用越多，选择器数量呈指数级膨胀，如%button-base被多处引用即生成多组带冗余祖先链的选择器。
@extend 不是复用，是选择器机械拼接；只要嵌套深或引用多，CSS 体积就指数级膨胀。
为什么 @extend 会让选择器爆炸式增长
@extend 编译时不做语义判断，只把所有调用它的选择器和目标选择器的完整路径“粘在一起”。比如你在 .modal 和 .card 里都 @extend %button-base，而 %button-base 又定义在 .layout .sidebar 下，Sass 就会生成：.layout .sidebar .modal, .layout .sidebar .card——哪怕你根本不需要这个祖先链。
- 嵌套每深一层，所有被
@extend的规则都会复制整条祖先路径 - 一个
%placeholder被 10 个组件引用，就可能产出 10 组完全重复的声明块，只是选择器前缀不同 - 浏览器不关心你写得“优雅”，它只解析最终 CSS；长选择器还可能触发 IE 的选择器长度限制（255 字符）
哪些场景下 @extend 实际上在增大体积
你以为在省代码，其实是在喂养冗余。常见高危用法：
- 对工具类（如
.u-text-center、.m-2）用@extend：这些类本身已是扁平结构，@extend只会让它们带上父级前缀，变成.card .u-text-center，完全违背工具类设计初衷 - 在嵌套块内
@extend外部占位符：.card { .header { @extend %heading; } }→ 可能生成.card .card .header这种诡异选择器 - 跨文件
@extend但没用@use显式导入，或导入顺序错乱，导致 Sass 拼接时 fallback 到全量路径匹配 - 继承目标本身含复合选择器（如
.utility .text-center），Sass 会原样保留整个结构，而不是提取语义
怎么验证你的 @extend 正在拖垮体积
别猜，直接看编译输出。运行：sass --watch src/main.scss:dist/main.css --style=expanded，然后打开 dist/main.css 手动搜索：
立即学习“前端免费学习笔记（深入）”；
- 找重复出现的声明块（例如同一组
display: flex; justify-content: center;出现几十次） - 看选择器是否普遍超过 4 层（
.a .b .c .d .e） - 检查是否有大量以相同前缀开头的选择器组（如全部以
.layout .main .section开头） - 确认
%placeholder是否真被至少一处@extend调用——未被调用的%会被彻底删除，你查不到它，也 debug 不到它
替代方案比硬扛 @extend 更可控
不是所有复用都该走 @extend。更安全的路径是分层决策：
- 纯功能、无上下文依赖的原子样式（如
%visually-hidden、%clearfix）→ 可谨慎用%placeholder + @extend - 需传参、需覆盖局部变量、或用于 BEM 组件内部 → 改用
@mixin，它只复制声明，不污染选择器 - 需要提级输出（比如组件内写的工具类不该带父前缀）→ 用
@at-root，而不是靠@extend“绕开”嵌套 - 第三方类名（如
.el-button）禁止@extend，否则构建时无法识别，PurgeCSS 也不敢删
真正难的不是写 Sass，是克制“看起来省了一行”的冲动——@extend 的陷阱在于，它让问题延迟暴露：开发时一切正常，上线后 CSS 文件突然翻倍，gzip 也救不回来。
