浏览器css选择器匹配从右往左进行，以关键选择器为起点定位并回溯验证，匹配发生在dom节点创建时且仅针对可见节点，性能取决于关键选择器类型与组合器决定的回溯路径长度。
选择器匹配不是“从左往右找后代”，而是从右往左定位再回溯验证——这是浏览器为了性能做的硬性设计，改不了，也绕不过。
关键选择器（key selector）决定匹配起点
浏览器不会先找 nav，再找它的 ul，再找 li，最后找 a；它会先抓所有 a 元素（或 a:hover），再逐个检查这些 a 的父链是否满足 li → ul → nav。
-
#header或.menu作 key selector 时最快，因为能通过哈希表直接定位节点 -
div、*、[data-id]作 key selector 时最慢，它们命中范围太大，要遍历大量节点 -
:nth-child(2n)这类伪类必须在匹配时实时计算，所以哪怕写成li:nth-child(2n) a，key selector 还是a，但每次验证都要回溯算父元素索引
匹配只发生在样式计算阶段，且仅对可见节点进行
匹配不是一次性动作，也不等页面加载完才开始——DOM 节点一创建，浏览器就立刻调用 cssMatcher.match(node) 流式匹配。
-
display: none的元素及其子节点完全不进渲染树，.hidden .btn这种规则根本不会去匹配它们 -
visibility: hidden的元素仍在渲染树中，照样参与匹配 - JS 动态加
class或data-*属性，会触发重匹配；但动态加普通属性（比如el.setAttribute('foo', 'bar')）不会触发，[foo]规则早已在节点创建时跑过了
组合器影响回溯路径和性能开销
空格（后代）、>（子）、+（相邻兄弟）、~（通用兄弟）不是语法糖，它们直接决定浏览器怎么走 DOM 链。
-
section article h2 + p的 key selector 是p，但匹配时得为每个p检查前一个兄弟是不是h2，再确认这个h2是否在article内 —— 回溯路径更长，比section article p慢 -
:has(ul > li.active)是双重反向：先按常规从右往左找候选元素，再对每个候选执行一次“从左往右”的后代查找，开销爆炸 -
.parent > .child比.parent .child更快，因为前者只需查直接父节点，后者要一路向上直到根
真正容易被忽略的，是匹配行为与 DOM 生命周期强绑定：节点创建即匹配，节点移除即清理，伪类状态变更是实时重跑——它不是静态快照，而是一套持续响应的流水线。写选择器时，想清楚“谁是 key selector”和“我要让浏览器查几层父链”，比纠结语法花哨重要得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
