@extend 仅适用于单类名或占位符，嵌套超3层会生成冗长选择器链，导致覆盖困难、定位失效及性能下降；应优先用@mixin处理参数化、响应式和状态变体。
嵌套超过3层时，@extend 会生成失控的选择器链
很多人以为用 @extend 能“继承语义”，结果编译出类似 .layout .sidebar .card .header .title 这种5级选择器——它不提升权重，但会让覆盖变得极其困难，且 DevTools 中几乎无法定位。根本原因是：@extend 是静态查找+拼接，一旦目标选择器本身含空格（如 .card .header），所有继承者都会被拖进完整路径里。
- 只对单类名（
.btn）或占位符（%text-center）使用@extend - 绝对不要
@extend .card__header或@extend .modal .close-btn，这类写法等于主动引入高特异性陷阱 - 运行
sass --watch --style expanded查看真实输出，确认没出现带空格的组合项 - 跨文件
@extend失效？检查@import顺序：占位符定义必须在引用前
& 在深层嵌套中极易指向错误父级
& 不是“视觉上缩进的上一级”，而是最近一层父选择器的完整字符串。写错一个空格，&__title 就可能从 .card__title 变成 .header__title，样式直接消失。
- 有空格：
.card { .header { &__title { } } }→ 编译为.header__title - 无空格：
.card { &__header { &__title { } } }→ 编译为.card__header__title（BEM 规范禁止这种嵌套） - 想稳定拼接外层上下文？用变量：
$block: ".card"; #{$block}__title { color: red; } - 检查
&前有没有空格——这是决定后代还是连缀的关键
真正该用 @mixin 而不是 @extend 的三种情况
当需要传参、响应式逻辑或状态变体时，@extend 直接失效。比如按钮颜色、尺寸、禁用态，@mixin btn($color, $size) 才是正解。
- 需要动态值：
@mixin link-colors($normal, $hover)，@extend不支持参数 - 含
@media或:not()等复杂上下文：嵌套里写这些会悄悄拉高权重，@mixin可控输出结构 - 组件有多个开关状态（
is-open/is-loading）：每个状态需独立 class，@extend无法拆分 - 第三方库样式覆盖？优先用
@layer overrides，而不是靠@extend拼权重
浏览器匹配性能在4层嵌套时明显下降
浏览器 CSS 匹配是从右往左的。.a .b .c .d .e 会让它先找所有 .e 元素，再逐层向上验证父级是否存在。DOM 节点越多，卡顿越明显。Lighthouse 明确提示 “Avoid overly specific selectors”。
立即学习“前端免费学习笔记（深入）”；
- 4 层是性能拐点：一旦出现
.nav .list .item .link，立刻重构为语义单类名（.nav-link） - 用
@at-root切断媒体查询嵌套：.btn { @at-root (with: media) { @media (max-width: 768px) { ... } } } - 子选择器
>比空格更可控：.card > .header > h1权重更低、更易覆盖、IE8+ 全支持 - 当嵌套开始描述 DOM 位置（如
div > ul > li > a），说明已脱离语义职责，该停手了
& 或 @extend 前，得先问一句：这个规则是否真属于当前组件的语义边界？还是只是因为“父容器里刚好有那个 class”？后者正是 !important 和调试崩溃的起点。 
