浏览器从右向左匹配CSS选择器是渲染引擎硬编码逻辑，关键选择器（最右侧）决定首轮扫描范围；#header、.btn等有索引，O(1)查找，而div、、[data-testid]等无索引需全量扫描，更会遍历所有节点及伪元素，大幅拖慢样式计算。
浏览器从右向左匹配 CSS 选择器，不是为了“看起来更顺”，而是渲染引擎硬编码的执行逻辑——它直接决定了哪些节点要被扫描、验证多少次、是否能跳过。性能问题几乎全来自你把什么放到了最右边。
关键选择器决定第一轮扫描范围
浏览器对每个 display != none 的 DOM 节点，逐条检查是否匹配某条 CSS 规则；第一步就是用选择器最右侧部分（即“关键选择器”）快速筛出候选节点。
- 好锚点：
#header、.btn、button——有哈希索引，O(1) 查找 - 坏锚点：
div、[data-testid="save"]、*——无索引，必须全量扫描所有节点 - 陷阱：
input[type="text"]看似具体，但属性匹配无索引，比加个.text-input类慢一个数量级
* { box-sizing: border-box } 这类通配符为什么特别伤性能
* 没有索引、无法剪枝，浏览器必须检查每个 DOM 节点——包括 <script>、<meta>、注释节点甚至 <!-- -->。哪怕只写一条，每次样式计算都触发全量遍历。
-
*::before和*::after更糟：1 个真实元素 → 生成 2–3 个伪元素 → 实际匹配节点数可能翻 2–3 倍（500 节点 → 1500+） - 它还会干扰继承优化：
html { font-size: 16px }本可自然向下继承，但* { font-size: 14px }强制重算每个节点 - 后续同级选择器也变慢：浏览器得先排除
*干扰，才能缓存其他规则的匹配结果
嵌套层级本身不慢，回溯验证才真正拖垮性能
写 section article header h1 不比 .title 多花 4 倍时间；真正耗时的是“向上跳转并比对”的次数。
立即学习“前端免费学习笔记（深入）”；
-
nav ul li a：先抓所有a，再对每个a验证是否在li内 → 是否在ul内 → 是否在nav内（三重回溯） -
.main-nav a：只抓所有带.main-nav的节点，再在其后代里找a（一次定位 + 后代遍历） - 超过 4 层的选择器（如
.container .sidebar .item .title span）在长列表页中极易引发Recalculate Style飙升、滚动掉帧
:has()、媒体查询和 data-testid 会悄悄抬高成本
这些内容不会被跳过，哪怕它们看起来“不生效”或“只在特定条件下启用”。
-
a:has(+ .warning)强制引入左向查找逻辑，目前仅 Chromium 支持且无法缓存，应避开关键路径 -
@media (prefers-reduced-motion)包裹的规则仍全程参与匹配，建议外链隔离非核心样式 -
[data-testid="save-btn"]出现在关键位置，等同于全量扫描，生产环境必须替换为.test-save-btn这类 class
真正影响性能的从来不是写了几个空格，而是你把哪个条件放到了最右边——那里是浏览器开始干活的地方，也是最容易失控的入口。很多页面 LCP/CLS 恶化，根源就藏在那条看似无害的 div#app main section > article p strong 里。
