浏览器css选择器从右向左匹配：先找最右元素，再向上验证祖先，深层后代选择器（如.a .b .c）导致o(n×depth)性能开销，应改用bem或子选择器优化。
浏览器从右向左匹配，不是“顺着DOM往下找”
很多人误以为 .container .list .item 是先找 .container，再在里面找 .list，最后找 .item。实际完全相反：浏览器先定位所有 .item 元素，再对每个 .item 向上遍历父节点，依次验证它是否在 .list 内、该 .list 是否在 .container 内。
这意味着 DOM 中每多一个 .item，就要做一次完整的向上路径检查。5000 个列表项 + 4 层嵌套，匹配开销不是线性增长，而是接近 O(n × depth) 量级。
- DOM 节点数超过 1400（Lighthouse 警戒线）后，
Recalculate Style时间会指数跳变 - 哪怕只加一层空格（如从
.card .title变成.card .content .title），在滚动或 hover 触发重算时，CPU 占用可能飙升 2–3 倍 -
devtools → Performance 面板 → Layout → matchRules堆栈频繁出现，基本可锁定为深层选择器问题
后代选择器（空格）比子选择器（>）更危险
.a .b .c 和 .a > .b > .c 看似只差一个符号，但匹配逻辑完全不同： （空格）不设层级上限，浏览器必须跨任意深度搜索；而 > 明确限定只查直接子元素，路径可控。
真实项目中常见陷阱：
-
nav ul li a:hover实际是 5 层，应改写为.nav-link:hover（2 层） - Sass 中
&__header &__title编译后变成.card__header .card__title，仍是空格分隔，没解决根本问题 -
div p在长列表页中每次 layout 都触发全量回溯，div > p至少能限制一层
特异性（specificity）飙升让后续维护雪上加霜
选择器层级每增一层，权重就+1。比如 .a .b .c .d 的 specificity 是 0,0,4,0，而 .d 只有 0,0,1,0。高权重直接带来硬性约束：
- JS 动态加类（如
el.classList.add('is-hidden')）很难覆盖，往往被迫加!important - DevTools 里“Computed”面板中，真正生效的规则被压在十几条失效规则下面，人工确认成本翻倍
- VS Code 的 CSS Peek 功能对深层嵌套支持弱，点击跳转常停在错误层级，而非真实命中位置
别信“SCSS 嵌套能优化性能”这种说法
& 是语法糖，不是作用域隔离机制。它生成的仍是标准 CSS 选择器，浏览器照常从右往左匹配，不会跳过任何一步。
典型反模式：
-
.card { .header { .title { color: red; } } }→ 编译出.card .header .title，3 层空格，匹配成本实打实 -
@at-root只适合媒体查询提级等场景，不能“修复”本不该存在的嵌套 - 真正有效的替代方案是 BEM 类名（如
.card__title）或 data 属性（如[data-role="title"]），前提是 HTML 中真实使用，而不是只在 SCSS 里写嵌套
最隐蔽的坑是：你改了 JS 或 HTML 结构，样式静默失效，但 DevTools 不报错——因为匹配逻辑本身没问题，只是路径断了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
