关键选择器决定第一轮节点筛选效率，浏览器从右向左匹配，#header、.btn等有索引的选择器为O(1)，而div、*、[data-id]等触发全量扫描；后代选择器层级越多、回溯越深，性能越差；:has()强制左查、媒体查询和[data-testid]在关键位置均显著拖慢样式计算。
关键选择器决定第一轮节点筛选效率
浏览器不是“读 CSS 去找元素”，而是对每个 display != none 的 DOM 节点，逐条判断“这条规则要不要应用到它身上”。这个判断过程固定从右向左，最右边那个部分（比如 a、.btn、[data-id]）就是关键选择器——它直接决定初始候选节点集有多大。
好锚点能走哈希索引：#header、.btn、button 这类有原生索引的选择器，查找是 O(1)；坏锚点则触发全量扫描：div、*、[data-testid="save"]，哪怕页面只有 500 个节点，也会挨个比对。
常见错误现象：
-
input[type="text"]看似具体，但属性匹配无索引，比加个.text-input类慢一个数量级 -
form * .error中的*在关键位置，等同于对每个节点做一次检查 -
[aria-hidden]单独用不慢，但作为关键选择器（如[aria-hidden] + button）就变成全量扫描
嵌套层级本身不慢，回溯验证才真正拖性能
写 section article header h1 并不比 .page-title 多花 4 倍时间；真正耗时的是“向上跳转并比对”的次数。每多一层空格分隔，浏览器就要对每个关键选择器命中节点，逐层向上验证父级结构是否满足。
立即学习“前端免费学习笔记（深入）”；
例如 nav ul li a：
- 先抓所有
a元素（可能上千个） - 对每个
a，检查其父是否为li→ 是否为ul→ 是否在nav内（三重回溯） - DOM 节点越多、嵌套越深，回溯路径越长，耗时呈非线性增长
实测：5000 节点页面中，4 层后代选择器比 BEM 单类名（如 .item__title）慢 3.2 倍，Recalculate Style 时间从 8ms 升至 26ms。
:has() 和媒体查询会悄悄抬高匹配成本
:has() 是目前唯一强制左向查找的伪类，Chromium 虽已支持，但无法缓存、不能索引，一旦出现在关键路径（如 article:has(.highlight)），就会让整个匹配逻辑退化为逐节点遍历。
媒体查询和测试属性也参与全程匹配：
-
@media (prefers-reduced-motion)包裹的规则，仍会被每个节点执行判断 -
[data-testid="xxx"]出现在关键位置，等同于全量扫描，生产环境应替换为.test-xxx -
*[hidden]或form *这类通配写法，必须删除——它们会让浏览器对每个 DOM 节点都跑一遍检查
高频更新区域尤其要避开空格选择器
在列表项、弹窗内容、实时评论流这类频繁增删节点的区域，使用 .list .item .content 这类空格分隔选择器，每次 DOM 变更都会触发昂贵的重匹配。浏览器得重新抓所有 .content，再逐个向上验证祖先链。
更稳妥的做法：
- 把样式锚点收窄到组件根节点，比如用
.comment-card .content替代.comments .comment .content - 用 BEM 类名（如
.comment__content）替代多层后代关系 - 避免在
hover、focus等状态变化频繁的规则里叠加复杂祖先条件
真正影响性能的从来不是写了几个空格，而是你把哪个条件放到了最右边——那里是浏览器开始干活的地方，也是最容易失控的入口。
