@extend 会让 CSS 顺序失效，因其将扩展选择器提至基础类定义处合并，导致后写的样式可能覆盖先写的；还会引发选择器爆炸、语义污染及响应式逻辑错乱等问题，应优先用 %placeholder 或 @mixin 替代。
@extend 为什么会让 CSS 顺序失效？
Sass 的 @extend 不是复制样式，而是“合并选择器”。它会把被继承的选择器（比如 .btn）的规则，注入到使用 @extend 的选择器（比如 .btn-primary）的声明块中——但实际生成时，Sass 会把所有用到 .btn 的地方，统一“提”到 .btn 原始定义的位置去合并。结果就是：你写在后面的 @extend，可能让前面的样式被意外覆盖。
- 如果
.btn定义在_base.scss里，而.btn-primary在_components.scss里通过@extend .btn调用，最终生成的 CSS 中，.btn, .btn-primary这个组合选择器会出现在_base.scss对应的输出位置，而不是你写@extend的地方 - 同一个基础类被多个地方
@extend，Sass 会把所有扩展它的选择器“塞进”同一个规则块，导致选择器爆炸（比如.a, .b, .c, .d, .e, .f {...}） - 一旦基础类带了属性（如
display: inline-block），所有继承者都会带上——哪怕你只想继承颜色和边框
@extend 和 %placeholder 的区别到底在哪？
%placeholder 是 @extend 的“静默版”，它本身不输出任何 CSS，只作为继承锚点存在；而 @extend 直接作用于真实类名，会强制生成对应选择器。
-
%btn-base可以被多次@extend，且不会产生冗余选择器，适合做纯抽象样式骨架 -
@extend .btn会把.btn的整个规则（包括它自己匹配的 HTML 元素）拖进来，容易污染语义结构 - 使用
%placeholder时，必须确保它定义在所有@extend之前，否则编译报错：Invalid CSS after "...": expected selector, was "}" - Sass 3.4+ 支持跨文件
%placeholder引用，但需用@import或@use显式加载，不能靠隐式依赖
哪些情况绝对不该用 @extend？
@extend 看似省代码，实则对可维护性很敏感，尤其在现代项目中。
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 涉及响应式断点：在
@media内部用@extend会导致断点逻辑错乱，Sass 会把扩展内容提到外层，破坏媒体查询封装 - 基础类本身用了
&:hover、&::before等伪类/伪元素：扩展后这些嵌套规则会被平铺展开，生成大量冗余选择器，比如.btn-primary:hover, .btn-secondary:hover {...} - 类名来自第三方库（如 Bootstrap 的
.alert）：它们的内部结构和覆盖逻辑不透明，@extend可能触发意料外的级联或 specificity 提升 - 需要动态切换样式（比如 JS 控制
class="btn btn--loading"）：扩展后无法单独控制子状态，因为样式已合并进父类规则
替代方案：什么时候该换用 @mixin？
@mixin 是更可控的复用方式，它本质是“复制属性”，不改变选择器结构。
立即学习“前端免费学习笔记（深入）”；
-
@include button-base()会在每个调用处原样插入属性块，保留独立选择器，利于调试和覆盖 - 可传参：
@include button-base($bg: #007bff, $border: none)，@extend完全不支持参数化 - 与
!default配合能实现主题变量回退，比如$btn-padding: 0.375rem 0.75rem !default; - 编译后体积略大（重复属性），但现代 gzip 压缩下差异微乎其微，远小于选择器爆炸带来的维护成本
CSS 生成逻辑藏得深，@extend 表面省几行，背后是选择器权重、顺序、复用粒度三重博弈。真要减重复，先想清楚：你是想“共享规则”，还是“共享意图”——前者用 %placeholder，后者直接上 @mixin 更稳。
