三层是分水岭，因浏览器从右往左匹配选择器，四层起回溯成本剧增、权重升至0-4-0导致覆盖失效；应改用BEM平铺、@at-root提级及@mixin封装响应式逻辑。
SCSS嵌套超过三层，基本就不是“写得细”，而是已经埋下覆盖失效的隐患——单个类名根本压不住编译出的 .page .layout .main .content p（权重 0-4-0），!important 会成为常态，而不是例外。
为什么三层是分水岭？
浏览器匹配选择器是从右往左执行的。四层嵌套如 .card .header .title .text，先找所有 .text 元素，再逐层向上验证父级是否存在。DOM 节点越多、嵌套越深，回溯成本越高；实测低端安卓设备上，5 层嵌套的 Recalculate Style 时间可达单类名的 4 倍以上。
- 权重跳变不可控：
.a .b .c .d是0-4-0，而你想用.highlight（0-1-0）覆盖它？几乎不可能 - DevTools 里规则灰掉、不生效，往往不是写错了，而是被更高权重的选择器静默压制
- Vue/React 的 scoped 样式（如
.btn[data-v-abc]）不会降低特异性，只是加了属性选择器——嵌套越深，最终生成的.a[data-v-x] .b[data-v-x] .c[data-v-x]权重照样飙升
哪些 & 用法必须立刻停用？
& 不是“当前模块前缀”，而是“上一层选择器的完整字符串”。在深层嵌套中，它会把整条路径原样拼进去，变成权重炸弹。
- 禁用：
.card { .header { .title { &.active { } } } }→ 编译为.card .header .title.active（0-3-0），但你本意可能是.card__title.active - 禁用：
.modal .content { &__body { } }→ 编译出.modal .content__body，这不是合法 BEM，浏览器 DevTools 会标黄警告“复杂后代选择器” - 禁用：
.item + .item { &:hover { } }→.item + .item:hover，逻辑可能完全错位，且权重比.item--hover高两级 - 特别注意：
&.active（同元素加类）和& .active（后代选择器）只差一个空格，四层缩进里极难肉眼识别
真正有效的替代方案
重点不是“怎么让 & 多钻两层”，而是“这一层 DOM 关系，值不值得用 CSS 层级去表达”。多数时候答案是否定的。
立即学习“前端免费学习笔记（深入）”；
- 用 BEM 平铺代替嵌套：
.product-card__title替代.card .body h3，编译后权重恒为0-1-0，浏览器一次匹配到位 - 状态类提级：
.card { @at-root .card--featured &__body { } }→.card--featured .card__body，跳出嵌套链但保留语义关联 - 交集逻辑脱离嵌套：
.form { @at-root button.primary { } }，而不是&.primary（那会产出.form.form.primary） - 响应式封装进
@mixin：@mixin responsive-title { font-size: 1rem; @media (min-width: 768px) { font-size: 1.25rem; } }，不靠嵌套撑结构
@at-root 不是万能解药，用错反而更糟
@at-root 只解决“选择器生成位置”，不解决“语义耦合”。它容易被当成“覆盖全局样式”的捷径，但实际作用非常有限。
- 错误写法：
.modal { .is-loading { @at-root .is-loading { opacity: 0.5; } } }→ 编译后仍是.modal .is-loading，根本没提级 - 正确写法：
.modal { @at-root .is-loading { opacity: 0.5; } }，且必须直接作用于目标选择器 - 媒体查询内需显式释放：
@at-root (without: all) .theme-dark才能脱离@media和父选择器双重包裹 -
&在@at-root内部无效：.card { @at-root &__header { } }直接报错，因为&依赖嵌套上下文，而@at-root已清除它
最常被忽略的一点：权重失控的根因，往往不是 SCSS 写法问题，而是 HTML 结构本身承担了太多样式职责——比如靠 div > div > ul > li > a 定位按钮，而不是给它分配一个语义明确的类名。删掉一层嵌套前，先问一句：这个元素，在 DOM 里有没有独立、可复用的身份？
