@extend 生成长选择器链是其工作机制决定的，会拼接调用处与定义处的完整祖先路径；避免爆炸需切断路径继承，而非降低嵌套或使用!optional。
直接说结论：@extend 生成长选择器链不是 bug，是它的工作机制决定的——它会把调用处的完整祖先路径和占位符定义处的路径一起拼进去。想避免爆炸，必须切断这种“路径继承”，而不是调低嵌套层级或改用!optional。
为什么 @extend 会在编译后塞进一堆没用的祖先类？
因为 @extend 不复制样式，而是把所有引用它的选择器“合并”进目标规则块，并忠实地保留它们各自的上下文路径。比如 %flex-center 定义在 .layout .sidebar 块里，而你在 .card 中写 @extend %flex-center，Sass 就会产出 .layout .sidebar .card 这种选择器——哪怕 HTML 里 .card 根本不在这层结构下。
- 跨文件引用时更危险：Dart Sass v7.0+ 默认开启模块隔离，但旧项目升级后若仍用
@import顺序混乱，%flex-center的定义路径可能被意外拉入 - 媒体查询或伪类会被一并拼接：
%btn-hover { &:hover { color: blue; } }被.btn和.modal .btn同时@extend，结果生成.btn:hover, .modal .btn:hover, .page .modal .btn:hover - 检查方法：打开编译后的 CSS，搜索占位符名（如
%flex-center），看前面有没有多出来的.page、.section等类名
哪些 @extend 写法几乎必然导致选择器爆炸？
以下模式不用测试就能预判会失控：
- 在嵌套规则内部使用：
.card { .header { @extend %text-sm; } }→ 可能生成.card .header, .card .title, .alert .header等一堆带.card前缀的变体 - 继承目标含
@media或&:hover：%btn-hover一旦被多处调用，断点和伪类会组合出指数级选择器 - 用具名类（如
.clearfix）而非%clearfix作继承目标：既输出无用的.clearfix类，又让所有调用者被卷入同一规则块 - 占位符里写了
display、margin、position等布局属性：换场景必须靠!important覆盖，违背继承初衷
怎么安全地用 % 占位符替代 @extend？
% 占位符本身不输出 CSS，只作为继承锚点，但它必须满足三个硬条件才不会反向制造问题：
- 必须以
%开头声明，例如%sr-only、%truncate；写成.sr-only或sr-only都无效 - 必须被至少一个
@extend调用，否则编译后彻底消失——你查不到它，也 debug 不到它 - 不能出现在嵌套规则内部：
.card { .title { @extend %heading; } }是危险操作，Sass 会尝试拼接.card .title和%heading的全部上下文路径，产出类似.card .card .title的冗余选择器 - 占位符里别写复合选择器，例如
.utility .text-center，否则继承者会得到.card .utility .text-center而非预期的.card .text-center
真正该用 @mixin 而不是 @extend 的场景
@extend 适合语义同类、样式完全一致、且永不单独存在的原子功能类；只要出现以下任一情况，就该立刻切到 @mixin：
- 需要传参（如
@mixin btn($color)）、响应式嵌套、或跨层级复用 - 涉及动态计算（如
lighten($color, 10%)）或状态变化（&:hover） - 要保证样式归属权独立：BEM 或 CSS Modules 项目中，
@extend会强行把.card__title和.list__item-title合并，破坏命名空间 - 想压缩体积但又不想冒爆炸风险：CSS 自定义属性（
--space-sm）比@extend更可靠，声明唯一，gzip 效果更好
最常被忽略的一点是：@extend 不会提升选择器权重，但它会拉高最终生成的选择器长度——这意味着匹配变慢、覆盖变难、老浏览器可能直接截断。与其花时间调试为什么 .page .section .card:hover 没生效，不如一开始就拒绝让它生成。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
