@extend生成超长选择器链是因为它合并选择器而非复制样式：当多个选择器继承同一占位符（如%flex-center），Sass将它们全塞入同一规则块；若占位符位于嵌套结构或跨媒体查询/伪类调用，还会拼接父路径与条件状态，导致选择器爆炸、解析变慢。
为什么 @extend 会生成超长选择器链
@extend 不是复制样式声明，而是把所有调用它的地方“合并进”被继承的选择器规则里。比如 %flex-center 被 .card-header、.modal-footer、.toast-body 三处 @extend，编译后就变成：.card-header, .modal-footer, .toast-body { display: flex; justify-content: center; }——这本身没问题。
但一旦 %flex-center 定义在嵌套结构里（比如 .layout { %flex-center { } }），Sass 就会忠实复现整个父路径，生成类似 .layout .card-header, .layout .modal-footer 这种带冗余上下文的选择器。
浏览器解析 CSS 是从右往左的，.a .b .c .d .e 这类长链显著拖慢匹配速度，尤其在旧版 Safari 和 IE 中可能触发选择器长度限制。
哪些 @extend 模式必然引发选择器膨胀
不是所有 @extend 都危险，但以下写法几乎一定导致输出失控：
立即学习“前端免费学习笔记（深入）”；
- 在嵌套规则内部使用：
.card { .header { @extend %text-sm; } }→ 编译后可能生成.card .header, .card .title, .alert .header等一堆带.card前缀的变体 - 跨文件引用未显式
@use的%placeholder：Dart Sass 7.0+ 默认隔离模块，找不到定义就静默失败或拼错路径，构建时可能漏掉某些扩展，开发者误以为要加更多@extend补救 - 继承目标含媒体查询或伪类：
%btn-hover { &:hover { color: blue; } }被多处@extend，结果所有继承者都获得 hover 样式，且无法单独关闭 - 用具名类（如
.clearfix）而非%clearfix作继承目标：既输出无用的.clearfix类，又让所有@extend它的地方被卷入同一规则块，体积和权重双双失控
为什么 @extend 会让 CSS 顺序失效
@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 是否已失控
别只看 SCSS 源码是否“简洁”，重点检查编译后的 CSS 输出和浏览器 DevTools 中的真实选择器行为：
- 运行
sass --watch src/main.scss dist/main.css --style=expanded，打开生成的 CSS 文件，搜索逗号分隔的选择器列表，看是否有超过 5–6 个并列项 - 在 DevTools 的 Styles 面板中，点击某个元素，观察右侧列出的匹配规则——如果看到大量带重复上下文（如
.card .header、.modal .header、.toast .header）的选择器，说明%header-center类已被不同上下文污染 - 注意
@extend后是否意外改变了特异性（specificity）：比如原本.btn是 0-1-0，被.card .btn继承后变成 0-2-0，可能破坏原有覆盖逻辑
真正难处理的不是写错语法，而是 @extend 把语义和位置耦合在了一起——当你开始为“DOM 层级”写继承，而不是为“功能意图”写占位符，问题就已经埋下了。
