浏览器卡在.a .b .c .d等长选择器上，因从右向左匹配导致回溯开销大；4层为性能临界点，易引发Recalculate Style飙升、覆盖困难及&指向错乱等问题。
为什么浏览器会卡在 .a .b .c .d 这种选择器上
不是SCSS编译慢，是浏览器运行时匹配太吃力。它从右往左查：先找所有 .d 元素，再逐层向上验证父级是否同时存在 .c、.b、.a。DOM越深、重绘越频繁（比如滚动列表），这个回溯过程就越占CPU。实测显示，.a .b .c .d 在低端 Android WebView 中 Recalculate Style 时间比 .a__d 高 3–5 倍。
- 4 层就是性能临界点，Lighthouse 直接报
Avoid overly specific selectors - Stylelint 的
selector-max-compound-selectors默认阈值是 3，超了就警告 - 嵌套本身不提升权重，但生成的长选择器会让特异性升到 0-4-0，后续覆盖只能靠
!important硬顶
为什么 & 符号在第4层开始“指错人”
& 永远只代表**紧邻上一层的选择器字符串**，不是缩进视觉里的“最外层”。嵌套越深，& 指向越反直觉，且会把整条路径权重一起带进去。
-
.card { .header { &__title { } } }→ 编译出.header__title（&指向.header，不是.card） -
.modal { & .overlay { } }→ 实际是.modal .overlay，若外层还有.page，就变成.page .modal .overlay - HTML 里没写
class="header"，那.header__title规则根本不会生效，但你可能以为是样式没加载
怎么判断你的嵌套已经失控
别靠缩进猜，直接看编译后的 CSS 文件——用 VS Code 按住 Ctrl 点击输出文件，或用命令批量扫描：
npx lessc input.less | grep -E "\.[a-z]+(\s+\.[a-z]+){3,}"
- 出现
.page .main .content .card .title这类 5 个 class 连续空格拼接，说明嵌套已失控 - DevTools 里找不到对应规则、组件挪到新容器就失效、
!important满天飞，这些都不是覆盖逻辑错了，而是选择器太长根本没被正确匹配上 - BEM 类名缺失（比如 HTML 写了
class="title"却漏了class="card"）会让&__title编译后完全不生效
替代方案不是“少嵌套”，而是“不依赖嵌套”
当嵌套开始服务于“DOM位置”而非“语义职责”时，就该停手了。比如 article section p em 这种写法，本质是样式逻辑错位。
立即学习“前端免费学习笔记（深入）”；
- 用
@at-root提级输出：@at-root .u-text-center { text-align: center; }→ 输出纯.u-text-center，不带任何父前缀 - 用
$block: ".card"显式拼接：#{$block}__title { color: red; }，避免靠&猜指向 - 子选择器
>更可控：.card > .header > h1比.card .header h1权重更低、更易覆盖，IE8+ 完全支持 - 真正需要复用时，优先用
%placeholder+@extend，但必须守铁律：以%开头、被至少一个@extend调用、不能出现在嵌套规则内部
