4层嵌套是浏览器CSS匹配性能临界点，因从右往左回溯匹配导致CPU飙升；&误用、@extend冗余及缺乏BEM规范加剧问题，需用@at-root、子选择器和文件级隔离解决。
嵌套层级过深直接导致浏览器匹配选择器时 CPU 开销飙升，不是“看起来不优雅”，而是滚动、重绘时真卡——4 层就是实测临界点。
为什么 4 层嵌套会让浏览器变慢
浏览器匹配 CSS 选择器是**从右往左**回溯的，不是顺着 DOM 树往下走。比如 .layout .sidebar .nav .item .link：
- 先找所有
.link元素 - 对每个
.link，检查它的父级是不是.item - 再查这个
.item的父级是不是.nav - 依此类推，直到确认最外层
.layout存在
DOM 越深、节点越动态（比如虚拟滚动列表），这个回溯链就越吃 CPU。低端 Android 设备上，4 层已触发明显卡顿；5 层以上，Recalculate Style 耗时常飙到 90%+。
常见现象：element.classList.add("is-active") 失效、DevTools “Computed” 面板里生效样式被压在几十条灰色规则下、改一个 class 要同步调三处 CSS —— 这些不是覆盖逻辑错了，是选择器太长，根本没被正确匹配上。
立即学习“前端免费学习笔记（深入）”；
& 符号误用让问题雪上加霜
& 永远只代表**紧邻上一层的选择器字符串**，不是视觉缩进里的“最外层”。有无空格，输出天差地别：
- 有空格：
.card { .header { &__title { } } }→ 编译出.header__title（&指向.header，不是.card） - 没空格：
.card { &__title { } }→ 编译出.card__title - 嵌套里再用
&：.card { .body { &__content { } } }→.body__content，和.card完全无关
更糟的是：如果 HTML 里没写 class="header"，这条规则就完全不生效，但开发者常误以为是“样式没加载”，反复加 !important。
@extend 在深层嵌套里会放大冗余
@extend 不是复用，是编译期机械拼接选择器。比如 .modal 和 .card 都 @extend %flex-center，结果生成：
.modal, .card { display: flex; justify-content: center; }
但一旦嵌套已深，比如写在 .layout .dashboard 下：.layout .dashboard .modal, .layout .dashboard .card —— 选择器长度直接翻倍。多个组件共用同一占位符时，逗号分隔列表爆炸式增长，CSSOM 构建时间显著上升。
关键限制：
-
%placeholder必须以%开头，且不能出现在嵌套规则内部（如.card { .title { @extend %heading; } }是危险操作） - 不能对动态类名（如
.btn--<code>size）用@extend，Sass 不支持运行时扩展 - 跨文件
@extend必须用@use显式导入，且目标必须是%开头
真正有效的切断手段只有三个
别指望压缩模式或工具链自动救场 —— --style compressed 只删空格换行，不碰选择器结构。真正要做的，是主动控制输出路径：
- 用
@at-root提级工具类：.modal { @at-root .u-text-center { text-align: center; } }→ 输出.u-text-center，不带任何父前缀 - 用子选择器
>替代空格：.card > .header > h1比.card .header h1更短、权重更低、更易覆盖 - BEM 不是命名规范，是匹配路径切断协议：
.card__title必须显式出现在 HTML 中，缺card就完全不匹配；禁止.card__header__logo这种跨层 Element
最容易被忽略的点：嵌套本身不提供作用域隔离。你以为 .modal { .header { } } 把样式锁在 modal 里，其实只是生成了更长的选择器，照样可能被外部高权重要素覆盖。真正的隔离靠文件拆分 + @use + 单一类名语义表达。
