@extend 会生成冗余选择器，因为它合并选择器链而非复制样式，导致跨文件、嵌套或媒体查询时重复输出；@mixin 通过文本插入避免选择器膨胀，但不支持继承式微调。
为什么 @extend 会生成冗余选择器
因为 @extend 不是复制样式，而是“合并选择器链”——它把被继承的选择器（比如 .btn）强行插入到所有引用它的选择器（比如 .btn-primary）的规则中，形成组合选择器。只要两个选择器在源码中不相邻、或中间隔着嵌套/媒体查询，Sass 就无法安全地复用原有规则，只能重复输出。
常见冗余现象：
-
.btn { color: blue; }和.btn-primary { @extend .btn; }在不同文件中引入时，.btn规则可能被多次注入 - 嵌套中使用
@extend（如&.active { @extend .btn; }），会生成类似.card .btn, .card .btn-primary的长选择器，而非复用.btn原始声明 - 跨媒体查询
@extend（如在@media (min-width: 768px)内 extend 全局.btn），Sass 必须把.btn的全部声明拷贝进媒体块，导致重复
@mixin 是如何避免选择器膨胀的
@mixin 本质是样式片段的文本插入，不涉及选择器关系分析。它只管把声明块原样塞进调用处的声明块里，完全绕过选择器合并逻辑。
对比示例：
@mixin btn-base {
color: blue;
padding: 4px 12px;
border: 1px solid #ccc;
}
.btn { @include btn-base; }
.btn-primary { @include btn-base; font-weight: bold; }
编译后仅生成两个独立规则，无共享选择器，也无跨上下文污染。但注意：它不会自动同步修改——改 btn-base 内容后所有 @include 处都会更新，这是优势；但若只想局部覆盖某条声明（比如只改 .btn-primary 的 color），就得额外写覆盖规则，不如 @extend 那样天然支持“继承后微调”。
何时该用 @extend，何时必须换 @mixin
选 @extend 只有一个强理由：需要语义化 CSS 类继承关系，且能接受选择器冗余风险。典型场景是 BEM 中的修饰符（.btn--large extend .btn）或主题类（.theme-dark extend .theme）。
其他情况基本该用 @mixin：
- 涉及响应式断点内的样式复用（
@extend在@media内行为不可控） - 目标类名本身是动态拼接的（如
.u-text-#{$size}），@extend不支持变量插入选择器 - 项目启用了 CSS 模块化（如 CSS Modules）或需要原子化 CSS（如 Tailwind），
@extend会破坏类名隔离或工具链假设 - 构建产物需压缩选择器长度（比如移动端对 CSS 文件体积敏感），
@extend生成的长组合选择器反而更难被 gzip 压缩
真实项目里最容易被忽略的坑
@extend 的作用域是全局的，哪怕写在嵌套规则里，也会提升到顶层解析。这意味着：
-
.card { .btn { @extend .icon; } }实际会让所有.icon的扩展逻辑都关联到.card .btn这个选择器，而不是局部生效 - 如果多个模块各自定义了同名占位符（
%reset），Sass 会合并它们，但顺序取决于 import 顺序，极易引发意料外的样式覆盖 -
@extend无法跨@forward/@use边界工作——用@use导入的模块中定义的占位符，不能被其他模块直接@extend，必须显式@forward出来
这些不是配置问题，是 Sass 解析模型决定的硬限制。一旦 CSS 体积开始异常增长或选择器行为诡异，优先查 @extend 的调用链和作用域穿透。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
