CSS选择器从右向左匹配，嵌套越深回溯越多、特异性越高，导致性能下降和维护困难；SCSS嵌套不优化性能，应采用BEM等扁平化方案。
浏览器从右往左匹配，嵌套越深回溯越多
CSS选择器不是从左到右“顺着找”，而是从右端开始定位目标元素，再逐级向上验证父级是否匹配。比如 .header .nav .item a:hover，浏览器先查所有 a:hover，再对每个匹配项检查它是否在 .item 内、该 .item 是否在 .nav 内……每多一层，就要多一次 DOM 树向上遍历。DOM 节点越多、嵌套越深（≥4 层），这个回溯过程就越耗时。
嵌套导致特异性飙升，覆盖和调试变困难
深层嵌套天然推高选择器权重（specificity）。.a .b .c .d 的权重是 0,0,4,0；而单类名 .d 只有 0,0,1,0。高权重会带来两个实际问题：
- 后续想用 JS 动态加类或写工具类（如
.is-hidden）覆盖样式，往往得加!important或写更重的选择器，形成恶性循环 - DevTools 里看到的“已计算样式”中，真正生效的规则可能藏在一堆被覆盖的旧规则下面，排查耗时翻倍
- 组件复用时，父容器一换（比如从
.page换成.modal），整套嵌套规则就失效，被迫复制粘贴或硬加!important
SCSS 嵌套不等于性能优化，& 用错反而雪上加霜
SCSS 的 & 是语法糖，编译后仍是普通 CSS 选择器，不会跳过浏览器匹配逻辑。常见误用包括：
-
.card { .header { .title { &.active { } } } }→ 编译出.card .header .title.active，4 层嵌套+高权重 -
.btn { .icon { &--small { } } }→&指向的是.icon，不是.btn，结果生成.icon--small，语义断裂 - 在
@media里继续&嵌套，比如@media (min-width: 768px) { .card { &__body { } } }→ 输出@media (min-width: 768px) { .card__body { } }看似没问题，但若外层还有嵌套，&就会展开全部路径，生成冗长不可控的选择器
真正有效的优化不是“少嵌套”，而是“不依赖嵌套”
关键不是把 SCSS 缩进删掉，而是重构样式组织逻辑：
立即学习“前端免费学习笔记（深入）”；
- 用 BEM 命名强制扁平：
.nav-list__item替代.nav .list .item，让每个类名自带语义且可独立存在 - 状态靠修饰符，不靠父级类：
.button--loading直接控制按钮自身状态，而不是等.form--submitting .button触发 - 用
@at-root主动提级：当某段样式逻辑上属于组件但不该继承嵌套路径时，直接提至顶层，避免无意义拼接 - 高频更新区域（如滚动列表项、动画容器）禁用任何空格分隔的选择器，哪怕只有两层 —— 因为每次 layout 触发，都要重跑整条匹配链
最常被忽略的一点：性能瓶颈往往不出现在“写了什么”，而出现在“改了什么”。一个 3 层嵌套的规则本身可能没问题，但当它被用于虚拟滚动中上千个动态插入的节点，并在 hover 时频繁触发 getBoundingClientRect()，那每一次匹配都会被放大成主线程卡顿。优化必须结合使用场景，不能只看选择器长度。
