4层及以上SCSS嵌套会引发真实性能卡顿与样式失效，因浏览器从右往左匹配时需逐级回溯父级，导致Recalculate Style耗时飙升、特异性失控、调试困难；应改用BEM命名、@at-root提级、限制嵌套深度至3层以内。
生产环境里，过深嵌套（4层及以上）的 SCSS 会直接产出高权重、低性能、难调试的 CSS，不是“写法不推荐”，而是上线后真会卡顿、失效、覆盖失败——尤其在低端 Android WebView 或长列表滚动场景下。
浏览器匹配选择器时，4层就是性能拐点
浏览器从右往左解析 .page .main .content .card .title：先找所有 .title 元素，再逐个向上验证是否在 .card 内、该 .card 是否在 .content 内……每多一层，就多一次 DOM 树回溯。实测表明：
- DOM 节点超 200 个（如商品卡片列表）时，
Recalculate Style时间飙升 3–5 倍 - 低端 Android 设备上，滚动掉帧、
hover延迟明显，.card__title比.page .main .content .card .title快 4 倍以上 - Chrome DevTools Performance 面板里能清晰看到样式计算耗时尖峰
权重失控让 !important 成为唯一出口
嵌套本身不提权，但编译后选择器长度暴增，导致特异性（specificity）直线上升：
-
.a .b .c .d权重是0,0,4,0；单类名.d只有0,0,1,0 - JS 动态加类如
el.classList.add('is-hidden')很难覆盖它，常被迫加!important或写更重的选择器 - DevTools “Computed” 面板中，真正生效的规则被压在十几条灰色失效规则底下，人工定位成本陡增
-
VS Code的 CSS Peek 功能对深层嵌套支持弱，点击跳转常停在错误层级
& 在深层嵌套里极易误判指向
& 不是“视觉上往上一层”，而是“上一层父选择器的完整字符串”。嵌套越深，& 行为越反直觉：
立即学习“前端免费学习笔记（深入）”；
-
.card { .header { &__title { } } }→ 编译出.header__title（&指向.header，不是.card） -
.modal { & .close { } }→ 编译出.modal .close，多一层无意义后代关系，权重+1 - BEM 类名缺失时，
&__title编译成.card__title，但 HTML 若没同时写class="card"和class="card__title"，规则完全不命中
真正有效的解法不是“少缩进”，而是切断匹配路径
别把嵌套当组织代码的手段。关键不是删掉缩进，而是用语义化方式让浏览器免于回溯：
- 改用 BEM 命名：
.card__title替代.card .title，匹配只需查单个类名，零回溯 - 用
@at-root提级工具类或兄弟组件样式：@at-root .u-text-center { text-align: center; }输出干净单类名 - 限制嵌套深度：用
stylelint-config-sass-guidelines配置max-nesting-depth: 3自动拦截 - 媒体查询里禁用
&嵌套：@media (min-width: 768px) { .card { &__body { } } }若外层还有嵌套，会生成 6 层以上选择器
最常被忽略的一点：问题不在 SCSS 语法，而在于用嵌套“模拟 HTML 结构”。CSS 应基于功能或状态组织，不是 DOM 深度镜像。删两层缩进，换一个 .card__title，比硬撑四层嵌套省事得多，也更可靠。
