浏览器css选择器匹配固定从右向左，因渲染引擎需先用最右侧选择器（如类名、id）快速筛选节点，再向上验证父级结构，失败早、开销小；若从左向右则需对每条规则全量遍历dom，效率极低。
浏览器不是“读取”CSS选择器，而是匹配 DOM 节点时执行选择器求值；这个求值过程固定为从右向左，这是渲染引擎（如 Blink、WebKit）的底层实现决定的，不是规范要求，但所有现代浏览器都这么做。
为什么不是从左到右？——匹配目标不同
CSS 匹配不是“找一个符合 .box p span 的路径”，而是“对当前 DOM 节点，判断它是否满足某条规则”。浏览器在构建渲染树时，是遍历每一个 DOM 节点（比如一个 <span class="red"></span>），然后挨个检查所有 CSS 规则，看哪条能应用到它身上。
如果从左到右匹配（比如先找 .box，再在其下找 p，再找 span），意味着每条规则都要从根开始往下钻——但绝大多数规则根本不会命中当前节点，白白浪费大量遍历。而从右到左，第一步就用最具体的条件（如 .red、#header、span）快速筛出“可能相关”的节点子集，再向上验证父辈结构，失败得早、开销小。
div#main ul li a:hover 实际怎么匹配？
假设当前正在处理一个 <a></a> 元素，浏览器会这样走：
- 先看它是否带
:hover状态（右侧最具体条件，直接可判） - 再看它的父元素是不是
<li> - 再看
<li>的父元素是不是<ul></ul> - 再看
<ul></ul>的祖先中是否存在id="main"的<div> <li>最后确认该 <code><div> 标签名确实是 <code>div（而非section之类）注意：中间任意一步不成立，整条规则立刻丢弃，不继续查。而如果从左开始，就要先找所有
div#main，再逐个展开其后代，效率呈指数级下降。哪些情况会打破“从右向左”？
极少数例外存在，但实际影响极小：
-
*出现在最右侧时（如div *），浏览器无法靠右端过滤，会退化为全量扫描——所以永远别写*.active或ul * - 某些伪类（如
:has()）强制需要左向查找，但目前（2026 年）仅 Chromium 实现且性能代价极高，应避免在关键样式中使用 - 属性选择器若无索引支持（如
[data-id]未配合 class/id），也可能拖慢右侧匹配速度
写 CSS 时真正要盯住的不是“顺序”，而是“右侧锚点”
所谓“优化选择器”，本质是控制最右边那个“切入点”的精确度。它决定了第一轮筛选的节点数量：
- 好锚点：
.btn-primary、#nav、button—— 类名/ID/标签名，有原生索引支持 - 坏锚点：
div（太泛）、*[aria-hidden]（无索引）、.container > *（右侧是通配） - 陷阱：
form input[type="text"]看似具体，但input是右侧，而[type="text"]属性匹配成本高；不如加个.text-input类
真正容易被忽略的是：这个机制只影响「匹配阶段」，不影响「层叠计算」或「重绘触发」。哪怕你写了完美的选择器，如果对应元素频繁增删或样式依赖
position: absolute导致脱离文档流，性能瓶颈也根本不在解析这里。 -
