浏览器从右往左匹配选择器，嵌套越深回溯越多，.page .main .content .card .title 这类5层选择器会遍历所有.title并逐层向上检查父级，导致CPU开销大、Recalculate Style飙升、滚动掉帧、hover卡顿；特异性过高（0,0,4,0）使JS动态加类难覆盖，DevTools调试困难，SCSS的&误用加剧耦合与权重，@at-root不解决深层嵌套问题，高频更新区域使用空格选择器会反复触发昂贵匹配，BEM类名（如.card__title）可规避但需HTML真实应用。
浏览器从右往左匹配，嵌套越深回溯越多
写 .page .main .content .card .title 这种 5 层选择器时，浏览器不是先找 .page 再往下钻，而是先遍历所有 .title 元素，再对每个 .title 向上检查是否在 .card 内、该 .card 是否在 .content 内……每多一层，就多一次 DOM 树向上遍历。DOM 节点越多（比如商品列表里有 200 个 .title），这个过程就越耗 CPU。
常见错误现象：Recalculate Style 时间在 Chrome DevTools Performance 面板里突然飙升；滚动时掉帧；hover 响应发卡——尤其在低端 Android 设备上，这类选择器可能比 .card__title 慢 4 倍以上。
特异性失控导致覆盖困难和调试成本上升
.a .b .c .d 的 specificity 是 0,0,4,0，而 .d 只有 0,0,1,0。高权重会直接带来两个现实问题：
- 后续用 JS 动态加类（如
el.classList.add('is-hidden')）很难覆盖它，往往得加!important或写更重的选择器 - DevTools 里“已计算样式”面板中，真正生效的规则常被压在十几条被覆盖的旧规则底下，人工定位要反复验证父级路径是否成立
- VS Code 的 CSS Peek 功能对深层嵌套支持弱，点击跳转常停在错误层级
SCSS/Less 的 & 不是作用域保护，用错反而加重问题
& 是父选择器的完整副本，不是缩进作用域。误用会生成更重、更耦合的选择器：
-
.card { .header { .title { &.active { } } } }→ 编译出.card .header .title.active，4 层+状态类，权重拉满 -
.btn { .icon { &--small { } } }→ 实际生成的是.icon--small，语义断裂，跟.btn完全脱钩 -
@at-root不是用来“救”深层嵌套的，它只适合切断本不该继承的前缀（比如媒体查询内提级），不是给 4 层缩进打补丁
真正影响性能的不是“写了什么”，而是“改了什么”
很多人盯着初始渲染，却忽略重排重绘场景。高频更新区域（如滚动列表项、动画容器）只要用了含空格的选择器（哪怕只有两层，如 .item .title），每次 layout 触发都要重跑整条匹配链。BEM 类名（如 .card__title）能彻底规避这个问题，但前提是 HTML 中真用这个类——而不是把 <h2 class="card__title"></h2> 改成 <div class="card__title"><h2></h2></div> 后还指望样式生效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
