浏览器匹配选择器从右往左，是CSS引擎固有机制；嵌套超3层如.page .section .content .card .title会先查所有.title再逐层回溯父级，导致性能下降、特异性飙升至0-5-0、覆盖困难，Lighthouse报“Avoid overly specific selectors”即源于此。
浏览器匹配选择器是从右往左的
这不是Sass的问题，是CSS引擎的固有机制。比如嵌套写成 .page .section .content .card .title，浏览器先找所有 .title 元素，再逐层向上验证父级是否依次为 .card、.content、.section、.page。DOM越深、更新越频繁，回溯开销越大——Lighthouse报“Avoid overly specific selectors”就源于此。
& 前有没有空格决定输出结构
& 永远只代表上一层的选择器字符串，不是视觉缩进的“父级”。一个空格之差，输出天壤之别：
- 有空格：
.card { .header { &__title { } } }→ 编译出.header__title（&指向.header，丢失.card上下文） - 没空格：
.card { &__header { &__title { } } }→ 编译出.card__header__title（纯拼接，但违反BEM：Element不能嵌套Element）
误读 & 是导致生成冗余长链选择器的最常见原因。
嵌套超过3层时，语义已让位于DOM路径
当嵌套开始模拟HTML结构（如 div > ul > li > a），说明样式逻辑错位了。这类写法本质是把CSS绑死在特定DOM位置，而非组件职责：
立即学习“前端免费学习笔记（深入）”；
- 组件无法复用到不同容器（比如
.tooltip既要在.header又要在.table-cell里出现） - JS动态增删class时，嵌套规则极易失效（React/Vue中className绑定逻辑变复杂）
- 内部有多个独立开关状态（
is-open/is-error）时，嵌套会迅速失控
此时不是嵌套写得不够深，而是该用 %placeholder、@mixin 或 BEM 命名替代。
编译后CSS里出现4个以上连续class就是失控信号
直接检查 .css 文件，而不是靠SCSS缩进猜。如果看到类似 .layout .sidebar .nav .item .link 这种5个class空格拼接的选择器，说明：
- 嵌套已超Sass官方推荐的3层上限
- 特异性升至0-5-0，比
.link难覆盖100倍 - 后续修改大概率要靠
!important硬顶，而DevTools里很难定位对应规则
真正关键不是“能不能嵌”，而是“编译后它到底生成了什么选择器、权重多少、是否还能被合理覆盖”。
