1.1 两种解析方向#

当我们写下这样的 CSS 规则时：

1
.container .item .title {
2
  color: red;
3
}

浏览器应该如何匹配这条规则？直觉告诉我们：应该从左向右，先找到 .container，再找它里面的 .item，最后找 .title。

然而，浏览器实际采用的是从右向左的解析方式：

1.2 一个简单的例子#

假设有如下 HTML 结构：

1
<div class="container">
2
  <div class="item">
3
    <span class="title">标题</span>
4
  </div>
5
  <div class="other">
6
    <span class="title">其他标题</span>
7
  </div>
8
</div>
9

10
<span class="title">独立标题</span>

选择器 .container .item .title 的匹配过程：

2.1 DOM 树的结构特点#

要理解为什么从右向左更高效，需要先理解 DOM 树的结构：

DOM 树的特点：

• 根节点唯一：从 document 开始
• 子节点众多：一个元素可能有几十甚至上百个子元素
• 层级嵌套深：现代网页的 DOM 树往往有 10+ 层

2.2 从左向右解析的问题#

假设采用从左向右的方式匹配 .container .item .title：

问题核心：从左向右需要大量遍历。每找到一个中间选择器，就要遍历其所有后代元素。

2.3 从右向左解析的优势#

从右向左的方式：

关键优势：只需要向上查找父元素链，而不需要向下遍历。

2.4 数量级对比#

用一个具体例子说明效率差异：

3.1 CSS 解析的整体流程#

CSS 从文本到样式计算的完整流程：

3.2 选择器的解析结构#

浏览器会将 CSS 选择器解析成内部结构：

3.3 选择器匹配算法#

WebKit 和 Blink 的选择器匹配算法核心逻辑：

1
// 简化的选择器匹配伪代码
2
bool matchesSelector(Element* element, Selector* selector) {
3
    // 从右向左匹配
4
    Selector* current = selector->rightmost();
5
    Element* currentElement = element;
6

7
    while (current && currentElement) {
8
        // 检查当前元素是否匹配当前选择器部分
9
        if (!matchCompundSelector(currentElement, current)) {
10
            return false;
11
        }
12

13
        // 移动到下一个选择器部分（向左）
14
        current = current->previous();
15

16
        // 对于后代选择器，向上遍历 DOM 树
17
        if (current && current->isDescendantCombinator()) {
18
            currentElement = currentElement->parent();
19
        }
20
    }
21

22
    return current == nullptr;
23
}

3.4 快速过滤机制#

现代浏览器会先进行快速过滤，减少需要精确匹配的元素数量：

4.1 渲染流水线中的位置#

CSS 选择器匹配是渲染流水线中的关键环节：

4.2 样式计算的核心步骤#

4.3 渲染树的形成#

样式计算完成后，形成渲染树：

关键点：display: none 的元素不会进入渲染树，也不需要样式计算。

5.1 选择器性能分级#

从快到慢的性能排序：

5.2 性能差异的原因#

5.3 后代选择器的性能代价#

后代选择器 A B 的匹配复杂度：

5.4 具体案例对比#

1
/* 好：使用类选择器 */
2
.title {
3
  color: red;
4
}
5

6
/* 较差：后代选择器 */
7
.container .item .title {
8
  color: red;
9
}
10

11
/* 最差：多层后代 + 通配符 */
12
.container * .item * .title {
13
  color: red;
14
}

性能对比：

6.1 选择器分组优化#

浏览器会对多个选择器进行分组处理：

6.2 样式继承缓存#

继承属性的计算结果会被缓存：

6.3 增量样式计算#

DOM 变化时，只重新计算受影响的部分：

6.4 JIT 编译选择器#

现代浏览器会使用 JIT 编译选择器匹配代码：

7.1 选择器书写原则#

7.2 BEM 命名方法#

BEM（Block Element Modifier）可以有效减少选择器嵌套：

1
/* 传统方式：3 层嵌套 */
2
.container .item .title {
3
  color: red;
4
}
5
.container .item--active .title {
6
  color: blue;
7
}
8

9
/* BEM 方式：单层选择器 */
10
.item__title {
11
  color: red;
12
}
13
.item--active .item__title {
14
  color: blue;
15
}

7.3 性能敏感场景的优化#

对于超大页面（如表格、列表），特别注意：

1
/* 避免：对所有行使用后代选择器 */
2
.table .row .cell .content {
3
  /* ... */
4
}
5

6
/* 推荐：直接类名 */
7
.cell__content {
8
  /* ... */
9
}

7.4 CSS-in-JS 的考量#

现代 CSS-in-JS 库通常会生成唯一的类名：

1
// CSS-in-JS 生成唯一类名
2
const styles = css`
3
  .title {
4
    color: red;
5
  }
6
`;
7
// 输出: .css-abc123-title

这种方式虽然增加了类名长度，但避免了选择器嵌套带来的性能问题。

8.1 解析方向对比#

8.2 XPath 的设计#

XPath 使用路径表达式，天然从左向右：

1
/html/body/div[@class='container']/div[@class='item']/span[@class='title']

XPath 的应用场景：

• XML 文档查询
• 需要精确定位的场景
• Web Scraping

8.3 jQuery 选择器实现#

jQuery 的 Sizzle 引擎也采用从右向左的解析：

Sizzle 的优化策略：

1. 快速查找：优先使用 getElementById、getElementsByClassName
2. 选择器分组：将复杂选择器分解
3. 结果缓存：缓存已匹配的结果

8.4 性能对比实验#

在 10,000 个元素的页面上测试：

9.1 Blink（Chrome）的实现#

Blink 的关键优化：

• 样式重置：快速确定哪些元素样式需要重算
• 无效化集合：精确追踪样式变化的影响范围

9.2 WebKit（Safari）的实现#

WebKit 的特点：

• Rule Tree：构建规则树避免重复计算
• Render Tree：紧密耦合渲染逻辑

9.3 Gecko（Firefox）的实现#

Gecko 的创新：

• Stylo：使用 Rust 实现的并行样式计算引擎
• 原子化：利用 Rust 的安全特性实现无锁并行

9.4 并行样式计算#

Firefox 的 Stylo 实现了并行样式计算：

并行计算的关键挑战：

• 依赖处理：父元素样式可能影响子元素
• 原子引用：使用 Rust 的原子类型避免数据竞争

10.1 核心原理回顾#

CSS 选择器从右向左解析的核心原因：

10.2 性能建议速查表#

10.3 设计哲学的启示#

CSS 选择器的解析设计体现了计算机科学的普遍原则：

1. 理解数据结构特点：DOM 树的特点决定了最优算法
2. 权衡是核心：简单性 vs 性能，需要找到平衡点
3. 持续优化：从 WebKit 到 Blink 到 Stylo，引擎在不断进化
4. 实用主义：标准规范与实现优化相辅相成

10.4 实践检查清单#

理解 CSS 选择器从右向左解析的原理，不仅能帮助你写出更高性能的 CSS，更能让你理解浏览器渲染引擎的设计哲学。在追求极致性能的场景下，这些知识将发挥重要作用。