关键选择器决定第一轮节点筛选范围，浏览器从右向左匹配，最右侧部分（如a、.btn）直接决定初始筛选节点；高区分度、有原生索引的条件应置于最右以避免全量扫描。
关键选择器决定第一轮节点筛选范围
浏览器不是“读取”整个选择器再判断匹配，而是对每个 DOM 节点单独做「是否符合这条规则」的判定，且这个判定永远从右往左执行。最右边那个部分（比如 a、.btn、[data-id]）就是关键选择器，它直接决定浏览器第一步抓哪些节点来验证。
这意味着：把高区分度、有原生索引的条件放在最右边，才能避免全量扫描。例如：
-
#header nav a：先找所有a元素（无索引，慢），再逐个向上查是否在nav里、是否父级有#header（两重回溯） -
#header .nav-link：先通过 ID 索引快速定位#header节点，再在其后代中查找.nav-link（一次定位 + 后代遍历，快得多）
单类名比组合选择器快，尤其在低端设备上
像 .card__title--hovered 这种 BEM 风格的单类名，浏览器可直接哈希查找一次命中；而 .card .card__title 会先找所有 .card__title 元素，再逐个向上检查父节点是否含 .card 类——DOM 层级越深、匹配节点越多，回溯开销越大。
实测在低端 Android 设备上，后者渲染耗时可达前者的 4 倍以上。这不是理论差异，是真实帧率瓶颈点。
常见误用场景：
- 用
input[type="text"]替代.text-input：属性匹配无索引，比加一个 class 慢得多 - 写
form input[data-testid="submit"]：测试属性无索引支持，[data-testid]放在关键位置 = 全量扫描 - SCSS 嵌套生成
.modal .content .header h2：4 层嵌套不等于 4 倍时间，但关键选择器是h2，触发对页面所有h2的回溯验证
:has() 和通配符选择器会强制打破右向优先逻辑
:has() 是目前唯一明确要求浏览器从左向右查找的选择器（例如 div:has(> button)），它无法被缓存、无法跳过，且 Chromium 尚未对其做深度优化。一旦出现在关键路径（如首屏样式表中），就会显著拖慢整个 CSSOM 构建。
同样危险的是通配写法：
-
*[hidden]：对每个 DOM 节点都检查hidden属性，必须删除 -
form *：匹配 form 下所有后代节点，无索引、无锚点，等同于暴力遍历 -
.container > *：右侧是通配符，失去关键选择器意义，退化为全量扫描
这些写法在开发期看不出问题，但在 200+ 节点的列表页或 SSR 渲染中，会成为 layout thrashing 的诱因。
媒体查询和测试属性不会被“跳过”，它们全程参与匹配
即使一条规则被 @media (prefers-reduced-motion) 包裹，它依然要参与每一轮 CSS 选择器匹配；浏览器不会因为当前不满足媒体条件就忽略这条规则的解析成本。
同理，[data-testid]、[aria-label] 这类属性选择器没有索引支持，只要出现在关键选择器位置（如 [data-testid="save-btn"]），就等效于对每个节点做字符串属性比对。
建议做法：
- 非核心样式（如暗色模式、动效开关）外链分离，用
loadCSS异步加载 - 测试属性全部剥离出生产 CSS，或改用带语义的 class（如
.test-save-btn） - 避免在关键选择器中混用属性 + 伪类（如
input:focus[disabled]），这类组合几乎无法被引擎优化
真正影响性能的从来不是你写了几个空格，而是你把哪个条件放到了最右边——那里是浏览器开始干活的地方，也是最容易失控的入口。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
