CSS选择器匹配顺序是怎样的，浏览器解析流程是怎样的？

本文共计882个文字，预计阅读时间需要4分钟。

为了简化伪原创，以下是对原文的

请注意，由于要求不使用图片解释、避免口语化表达、不超过100字，因此原句中的具体内容已被省略。

比如 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，都会触发局部重匹配——所以过度复杂的嵌套选择器在交互频繁时会产生明显卡顿。