浏览器解析css选择器从右往左匹配，嵌套超3层（如.page .main .content .card .title）需逐级向上回溯验证父级，dom越深、更新越频繁，匹配耗时越长，4层即为性能临界点。
为什么嵌套超过3层会让CSS匹配变慢
浏览器解析选择器是**从右往左**匹配的。.page .main .content .card .title这种写法，引擎得先找所有.title元素，再逐个向上验证父级是否满足.card→.content→.main→.page。DOM节点越多、更新越频繁（比如滚动列表），这个回溯链就越吃资源。
这不是SCSS编译慢，而是它生成的CSS本身在运行时拖累渲染。每多一层空格分隔的选择器，特异性就升高一级，还容易触发意外覆盖。
- 4层是临界点：一旦出现
.a .b .c .d，优先重构，别硬扛 - 后代选择器（空格）比子选择器（
>）更不可控——后者能切断继承链，但也不能靠它“救”深层嵌套 - 标签名嵌套（如
ul li a）最危险：HTML结构一变，样式全挂
怎么用BEM真正切断嵌套依赖
BEM不是加几个下划线，是把语义“拍平”进类名里。.nav__item不依赖.nav是否存在，也不关心它在不在.header里。样式只认一个class，耦合点从N个降到1个。
常见错误是名义上用BEM，实际仍靠嵌套保底。比如写.card { .header { &__title { } } }，结果&指向.header，编译出.header__title，直接破坏BEM结构。
- 必须显式写出基础Block类：
<div class="card"> <h2 class="card__title">，缺<code>card就完全不匹配 -
&__title前面不能有空格；.card { &__title { } }→.card__title，但.card { .title { &--large { } } }→.title--large - Element不能嵌套Element：
card__header__title违规，应拆成card__header和card__title两个独立元素 -
@at-root .u-text-center { text-align: center; }→ 输出为.u-text-center，不带任何父前缀 - 配合
with:可选择性提级：@at-root (with: .theme-dark) { .button { color: white; } }→.theme-dark .button - 别在
@media里滥用&嵌套：@media (min-width: 768px) { .card { &__body { } } }看似干净，但外层若还有嵌套，&会展开全部路径，生成冗长不可控的选择器 - DevTools里选中元素 → Computed → Styles → 看规则对应的选择器是不是单类名（如
.form__input），而不是.form .input - 终端快速扫描：
grep -r "\.[a-z]\+ \.[a-z]" src/css/，能揪出所有含空格的选择器 - 伪类和响应式也要守规矩：
.button--loading:hover语义错（按钮自己hover？），应改用.button--loading+ JS切换.button--hovered状态
@at-root不是语法糖，是提级控制开关
当某段样式逻辑上属于组件，但不该继承当前嵌套路径时，@at-root能强制把它提到顶层输出，避免无意义拼接。比如在.modal嵌套里写工具类或兄弟组件样式，硬撑嵌套只会让CSS膨胀。
它不解决根本问题，但能帮你“局部止损”。真正要防的是把@at-root当补丁反复贴，最后还是得重构。
怎么检查你写的SCSS是否真扁平化了
光看SCSS源码没用，得看最终生成的CSS字符串。很多团队以为用了BEM就安全了，结果构建后还是满屏.block .element。
关键检查点就两个：有没有空格分隔的选择器、修饰符能不能独立生效。
最常被忽略的一点：性能瓶颈往往不出现在“写了什么”，而出现在“改了什么”。一次DOM更新触发重排，深层选择器的匹配代价就立刻暴露出来。
