浏览器从右往左匹配CSS选择器是为了快速筛除不匹配元素：先定位最右的关键选择器（如.class或ID），再向上验证父级，关键选择器越具体（如稀有class）效率越高；若从左往右则需遍历大量无关节点，性能显著下降。
为什么浏览器从右往左匹配 CSS 选择器
因为这样能更快地筛掉大量不匹配的元素。浏览器先定位关键选择器（最右边那部分），比如 .btn 或 div，再向上逐级验证父级条件。如果关键选择器本身命中率低（比如一个罕见的 class），整个规则就几乎不用继续比对了。
反过来看，如果从左往右，就得先找所有 nav 元素，再在每个里面找 ul，再找 li，最后才看有没有 .active——哪怕页面里只有 1 个 .active，也要遍历全部 nav ul li 组合。
- 关键选择器越具体、越稀有，性能越好；越宽泛（如
*、div），性能越差 - ID 和 class 是高效的关键选择器；标签名和通配符是低效的关键选择器
- 写
div#header .nav a:hover时，真正起决定作用的是a:hover，不是div
后代选择器（空格）为什么比子选择器（>）更慢
后代选择器要向上遍历任意层级的祖先，而子选择器只查直接父级。浏览器对每个匹配到的右端元素（比如所有 a），都要一路往上翻 DOM 树，直到根节点或满足条件为止。
尤其当关键选择器是低区分度的标签（如 p、span）时，这个过程会非常耗时。子选择器虽然也需向上查一层，但路径长度固定为 1，开销可控。
立即学习“前端免费学习笔记（深入）”；
- 避免
body div p span em这类长链后代选择器 - 用 class 替代多层标签嵌套：
.user-info__name比.user-info div p span快得多 -
.list > li > a比.list li a更可预测、更轻量，尤其在动态增删 DOM 时
属性选择器和伪类作为关键选择器有多伤性能
像 [data-id="123"]、:nth-child(2n) 这类选择器，浏览器必须检查每个元素是否满足该条件，无法靠哈希或索引快速定位。它们天然不具备“跳过”能力，属于线性扫描型匹配。
更麻烦的是，这类选择器一旦出现在关键位置（最右边），就会让整条规则变成“全量扫描 + 逐个验证”的模式，无论页面结构多简单，开销都接近 O(n)。
-
a[href^="https"]比.external-link慢一个数量级，尤其在链接密集的页面 -
input[type="text"]:focus的关键选择器是:focus，它本身是动态伪类，每次重绘都可能触发重匹配 - 真要用属性匹配，优先加 class 做前置过滤：
.form-input[data-type="email"]，让关键选择器落在.form-input上
class 名带连字符或 BEM 风格会影响性能吗
不影响。浏览器解析 class 名是按字符串精确匹配，不涉及正则或分词，user-name 和 userName 在性能上完全等价。BEM（如 btn__icon--large）带来的额外字符对匹配速度无实质影响。
真正影响性能的是 class 的复用程度和是否被合理用于关键选择器。一个命名再“规范”的 class，如果被滥用在超长后代链里（比如 .header .nav .item .link），照样拖慢渲染。
- 别为了“语义化”堆砌多层 class：用
.search-form__submit就够了，不需要再写.search-form .form-group .btn - 避免在关键选择器位置使用低频 class，比如只在某页用一次的
.page-404__hero-text - 工具如 Chrome DevTools 的 “Rendering” 面板可开启“Paint flashing”，配合强制重排观察选择器实际影响范围
