渲染引擎从右向左匹配CSS选择器，先用关键选择器（最右部分）快速筛选候选节点，再向上验证祖先结构，任意一层不满足即丢弃；关键选择器需有索引支撑（如ID、class），避免全量扫描。
浏览器不是“找匹配的节点”，而是“问每个节点配不配”
渲染引擎构建渲染树时，是遍历每一个 display != none 的 DOM 节点，再拿所有 CSS 规则逐条去“验身”：这个节点要不要应用这条样式？不是从 CSS 规则出发去找元素，所以没法“从左开始顺藤摸瓜”。
从右向左能早失败、少浪费：
• 先用关键选择器（如 a:hover 中的 a:hover）快速筛出候选节点子集
• 对每个候选节点，再向上验证父级结构（比如是否在 .nav 内、是否被 #header 包裹）
• 任意一层不满足，立刻丢弃，不继续查祖先链
• 若从左向右，就得对每条规则都从 html 开始往下钻——哪怕 99% 的节点根本不会命中，也得白跑一遍
关键选择器决定第一轮筛选快慢
关键选择器就是整个选择器最右边那个部分，比如：
• nav ul li a 的关键是 a
• .main-nav > a 的关键是 a
• form input[data-id] 的关键是 input[data-id]
浏览器靠它做初始过滤：
• 好锚点：#header、.btn、button —— 可哈希查表，O(1)
• 坏锚点：div、*、[data-testid="save"] —— 触发全量 DOM 扫描
• 陷阱：input[type="text"] 看似具体，但属性匹配无索引，比加个 .text-input 类慢一个数量级
嵌套层级不直接拖慢，但回溯验证次数会指数级增加
写 section article header h1 并不比写 .title 多花 4 倍时间；真正耗时的是“向上跳转并比对”的次数：
• nav ul li a：先抓所有 a，再对每个 a 检查其父是否为 li → 是否为 ul → 是否在 nav 内（三重回溯）
• .main-nav a：只抓所有带 .main-nav 的节点，再在其后代里找 a（一次定位 + 后代遍历）
• 实测显示，嵌套超 3 层后，样式计算耗时平均上升 40% 以上，尤其在低端安卓 WebView 中更明显
• :has() 会强制引入左向查找逻辑，目前仅 Chromium 支持且无法缓存，应避开关键路径
伪类、媒体查询和测试属性悄悄抬高成本
这些内容不会被跳过，哪怕它们看起来“不生效”：
• a:hover 的关键是 a，但每次匹配都要实时判断 hover 状态
• @media (prefers-reduced-motion) 包裹的规则，仍全程参与匹配，建议外链隔离非核心样式
• [data-testid="save-btn"] 出现在关键位置，等同于全量扫描，生产环境应替换为 class
真正容易被忽略的是：性能瓶颈不在“写了多少层”，而在“关键选择器有没有索引支撑”以及“回溯路径是否可控”。div * 或 ul * 这类写法会让浏览器退化为全量扫描，必须杜绝。
立即学习“前端免费学习笔记（深入）”；
