当样式需完全一致且语义同类（如所有按钮共用 .btn）时应使用 @extend，它合并选择器以减少体积；而需传参或跨层级、嵌套场景则必须用 @mixin。
什么时候该用 @extend 而不是 @mixin
当你有一组样式必须「完全一致」且语义上属于同一类（比如所有按钮都该有 .btn 的基础外观），@extend 才真正有用。它把选择器合并进被继承的规则里，生成更紧凑的 CSS；而 @mixin 是复制样式块，每次调用都重复输出——对公共重置、工具类或原子类来说，@extend 更省体积。
常见错误现象：@extend 在嵌套选择器里乱用，比如在 .card .header 里 @extend .text-sm，结果生成一堆冗余组合选择器，反而增大 CSS 体积。
- 只对顶层、语义清晰的占位符（
%button-base）或真实类（.btn）使用@extend - 避免跨层级继承：不要在
&:hover或@media块里@extend外部定义的类 - 如果需要传参（如颜色、尺寸），必须用
@mixin——@extend不支持参数
@extend 后选择器爆炸？检查是否用了复杂选择器
Sass 的 @extend 本质是「查找并合并选择器」，一旦你继承的目标本身带有多层结构（比如 .layout .sidebar .nav-item），所有引用它的地方都会被展开拼接，导致最终 CSS 里出现大量长选择器，甚至触发浏览器的「选择器长度限制」（尤其 IE）。
典型错误场景：用 @extend .u-text-center，但 .u-text-center 是从 .utility .text-center 编译来的——Sass 会忠实复现整个路径。
立即学习“前端免费学习笔记（深入）”；
- 公共样式尽量用单类名定义，例如
%text-center或.t-center，而非依赖 DOM 结构的复合类 - 用
%placeholder（以%开头）定义仅用于继承的抽象样式，它不会单独输出 CSS - 运行
sass --watch时加--style expanded查看编译后的真实选择器，确认没意外膨胀
继承链断裂？注意 @extend 的作用域和顺序
@extend 不是动态查找，它只认「已声明」的祖先规则。如果你在文件 A 里定义了 %reset，又在文件 B 里 @extend %reset，但 B 被 import 到 A 前面，Sass 就会报错："%reset" is not a valid selector。
另一个隐形坑：CSS 优先级不会因为 @extend 改变。比如你 @extend .btn-primary，但目标类本身权重低（.btn），继承后的选择器还是只有单类权重，覆盖不了 #header .btn 这种高权重要求。
- 所有被
@extend的占位符或类，必须在继承语句之前定义（import 顺序很重要） - 别指望
@extend提升选择器权重——它只是复用样式声明，不改变选择器本身 - 如果要保证权重一致，继承后手动补一个同级类（如
.btn.btn-secondary），而不是只靠@extend
兼容性与构建影响：现代项目慎用深度 @extend
PostCSS、PurgeCSS 等工具依赖静态分析选择器，而 @extend 生成的选择器是运行时拼出来的，容易被误删。比如你 @extend %hidden，但 PurgeCSS 没在 HTML 里看到 %hidden，就可能把整块样式干掉。
另外，LibSass（旧版 Sass）对嵌套 @extend 支持不稳定，Dart Sass 虽然修复不少，但在循环 + @extend 组合下仍有边界 case 报错。
- 用 Dart Sass（
sassnpm 包），别用已废弃的node-sass - 开启
--no-source-map和--style compressed时，@extend错误提示会变弱，建议开发期用expanded模式调试 - 如果项目用了 PurgeCSS，把所有
%placeholder名加到whitelistPatterns里，例如/^%/
真正难的是判断「这个公共样式到底该抽成 % 占位符，还是保持为独立类供 HTML 直接写」——前者省 CSS 体积，后者保 HTML 可读性和工具链友好度。选哪个，得看你团队对构建稳定性和维护成本的容忍线在哪。
