4层嵌套是浏览器选择器匹配临界点，.a .b .c .d会导致CPU飙升；&符号误用、@extend滥用、未控权重均加剧性能问题，应以语义职责而非DOM位置组织嵌套。
嵌套过深不是“写法不够优雅”的问题，而是浏览器匹配选择器时真会卡死——4 层就是实测临界点，.a .b .c .d 这种选择器会让 CPU 在滚动、重绘时飙高到 90%+。
浏览器从右往左匹配，每多一层就多一次回溯
浏览器不按 DOM 树从上往下找，而是先抓所有 .d 元素，再逐层向上验证父级是否为 .c、.b、.a。DOM 越深、节点越动态（比如虚拟滚动列表），这个回溯链就越吃 CPU。
- 3 层嵌套：
.card .header .title→ 特异性 0-3-0，回溯 2 次 - 4 层嵌套：
.layout .sidebar .nav .item→ Lighthouse 明确报 “Avoid overly specific selectors” - 5 层以上：低端 Android 设备上 Recalculate Style 耗时常超 100ms，用户感知明显卡顿
& 符号误用让输出完全失控
& 只认紧邻上一层的选择器字符串，跟缩进无关。空格有无，输出天差地别：
- 有空格：
.card { .header { &__title { } } }→ 编译出.header__title（&指向.header） - 没空格：
.card { &__header { } }→ 编译出.card__header - 嵌套里再用
&：.card { .body { &__content { } } }→.body__content，和.card完全无关
更糟的是：如果 HTML 里没写 class="header"，这条规则根本不会生效，但开发者常以为是“样式没加载”，反复加 !important。
立即学习“前端免费学习笔记（深入）”；
@extend 在深层嵌套里会爆炸式复制选择器
@extend 不是复用，是编译期机械拼接。一旦嵌套已深，它就把整条祖先链复制进去：
- 在
.layout .dashboard下写.modal { @extend %flex-center; } - 结果生成：
.layout .dashboard .modal, .layout .dashboard .card（如果.card也@extend了同一占位符） - 多个组件共用一个
%placeholder，逗号分隔列表直接指数级增长，CSSOM 构建时间飙升
%placeholder 必须以 % 开头，且不能出现在嵌套规则内部（如 .card { .title { @extend %heading; } } 是危险操作）。
真正该用 @at-root 和 > 切断继承链
嵌套里写 @media 或 :not() 时，很容易把权重悄悄拉高。@at-root 和子选择器 > 是唯一可控手段：
-
.btn:hover { @at-root (with: media) { @media (max-width: 768px) { color: red; } } }→ 输出平级@media规则，不增加权重 -
.card { > .header { > h1 { } } }→ 编译为.card > .header > h1，比.card .header h1更短、权重更低、更易覆盖 -
>在 IE8+ 完全支持，但不适用于需要穿透多层的场景（如全局按钮主题），此时应改用类名或data-属性
最常被忽略的一点：嵌套一旦开始服务于“DOM 位置”而非“语义职责”，比如 div > ul > li > a 这种纯路径写法，就该立刻停手——这不是组织代码，是在给浏览器埋雷。
