浏览器选择器匹配从右向左进行，关键选择器（最右侧部分）决定初始筛选节点范围，高效锚点如#header、.btn可O(1)查找，而div、*[aria-hidden]等无索引选择器会引发全量扫描，嵌套层级本身不直接导致性能下降，真正耗时的是回溯验证次数。
浏览器不是“读取”选择器，而是对每个 DOM 节点逐个判断它是否匹配某条规则；这个判断过程固定从右向左，所有现代引擎（Blink、WebKit）都如此实现——这不是可选行为，而是底层事实。
关键选择器决定第一轮筛选范围
所谓“关键选择器”，就是整个选择器最右边那个部分，比如 .nav-link 在 header nav .nav-link 中，a 在 ul li a 中，[data-id] 在 form input[data-id] 中。它直接决定浏览器第一步要抓哪些节点来验证。
- 好锚点：
.btn、#header、button——有原生索引，O(1) 查找 - 坏锚点：
div（太泛）、*[aria-hidden]（无索引）、.container > *（右侧是通配符） - 陷阱：
input[type="text"]看似具体，但属性匹配无索引，比加个.text-input类慢得多
嵌套层级不等于性能开销，回溯路径才真正拖慢匹配
写 section article header h1 并不比 .title 多花 4 倍时间，真正耗时的是“向上验证”的次数：每多一层父级约束，就要多一次 DOM 节点跳转和类型/属性比对。
-
nav ul li a：先抓所有a，再逐个查是否在li内、是否在ul内、是否在nav内——三重回溯 -
.main-nav a：只抓所有带.main-nav的节点，再在其后代里找a——一次定位 + 后代遍历，开销低得多 - 伪类如
:has()强制左向查找，目前仅 Chromium 实现且无法缓存，应避开关键路径
媒体查询和测试属性会悄悄抬高匹配成本
哪怕规则被 @media (prefers-reduced-motion) 包裹，它依然全程参与匹配；data-testid 这类属性选择器没有索引支持，一旦出现在关键位置（如 [data-testid="save-btn"]），就等同于全量扫描。
立即学习“前端免费学习笔记（深入）”；
- 媒体查询无法被跳过，建议外链隔离非核心样式
- 测试用属性应剥离出生产 CSS，或改用 class（如
.test-save-btn） -
*[hidden]或form *这类通配写法，会触发对每个 DOM 节点的检查，必须删除
真正影响性能的从来不是“写了几个空格”，而是你把哪个条件放到了最右边——那里是浏览器开始干活的地方，也是最容易失控的入口。
