CSS选择器从右到左匹配，先定位最右的关键选择器（key selector），再向上回溯验证；class/id因哈希查找高效，而通用/属性选择器匹配慢；伪类、逻辑函数及DOM变动会显著增加匹配开销。
CSS 选择器是从右到左匹配的
浏览器解析 CSS 选择器时，并不是按书写顺序从左往右“找父元素再找子元素”，而是反向：先定位最右边的选择器（称为 key selector），再向上回溯验证是否满足整个规则。这是为了性能优化——避免对大量无关节点做无谓的祖先链检查。
比如 nav ul li a:hover，浏览器会：
- 先收集所有
a:hover元素（极小集合） - 对每个
a，检查其父元素是否为li - 再检查该
li的父元素是否为ul - 最后检查该
ul是否在nav内
为什么 class 和 id 选择器做 key selector 更高效
因为 .menu 或 #header 能直接通过哈希表快速定位节点，而通用选择器如 div、* 或属性选择器 [data-id] 匹配范围大，会显著拖慢匹配过程。
常见低效写法：
立即学习“前端免费学习笔记（深入）”；
-
div#main ul li a——div是冗余前缀，#main已唯一 -
*[role="button"]——*强制遍历全部节点 -
section article h2 + p——p是 key selector，但相邻兄弟关系需逐个比对前一个节点
伪类和伪元素会影响匹配起点
:hover、:nth-child() 等伪类属于 key selector 的一部分，浏览器必须在匹配阶段实时计算状态。这意味着：
-
li:nth-child(2n) a的 key selector 是a，但每次匹配a时都得回溯确认其父li是否满足2n -
a::before的 key selector 是a，伪元素本身不参与 DOM 树匹配，只在渲染树生成阶段插入 -
:is(), :where(), :has()这类逻辑函数会让匹配复杂度飙升：:has(ul > li.active)要为每个候选元素检查其后代，实际是“从右往左”再嵌套一层“从左往右”
浏览器解析 CSS 的完整流程中，选择器匹配只是中间一环
完整链条是：HTML 解析 → 构建 DOM 树 → 加载并解析 CSS → 构建 CSSOM → 合并 DOM + CSSOM → 生成渲染树（Render Tree）→ 布局 → 绘制。选择器匹配发生在“生成渲染树”阶段，且仅对 display != none 的元素进行。
这意味着：
- 被
display: none的元素不会进入渲染树，其后代即使有样式也不会被选择器匹配（例如.hidden .btn不会匹配任何节点） -
visibility: hidden的元素仍参与匹配，因为它仍在渲染树中 - @media 查询和
prefers-color-scheme等条件规则，会在 CSSOM 构建阶段就筛掉不生效的规则，减少后续匹配负担
真正容易被忽略的是：选择器匹配不是一次性动作。DOM 变动（如 class 切换、节点增删）、伪类状态变化（:hover、:focus）、甚至视口滚动触发的 :target，都会触发局部重匹配——所以过度复杂的嵌套选择器在交互频繁时会产生明显卡顿。
