2、React渲染机制：虚拟DOM的工作原理、Fiber架构与调度、协调与Diff算法

说实话，React的渲染机制是我当年入坑时最头疼的部分。那时候我写了个列表组件，数据一变整个页面都闪一下，用户体验差到被产品经理追着骂。后来我才明白——不搞懂虚拟DOM和Fiber，你写出来的React应用迟早要翻车。

这一节，咱们就把React的渲染机制掰开揉碎了讲。我会结合自己踩过的坑，帮你彻底搞懂这三个核心概念。

2.1 虚拟DOM：为什么要有它？

先问个问题：直接操作真实DOM有什么问题？

我当年做jQuery项目时深有体会。每次更新数据，要么innerHTML一把梭，要么手动操作DOM节点。前者性能差，后者代码乱。说白了，真实DOM的操作成本太高了——每次修改都可能引发重排重绘。

虚拟DOM就是来解决这个问题的。它本质上是一个轻量级的JavaScript对象，模拟了真实DOM的结构。

// 虚拟DOM长这样
const vnode = {
  type: 'div',
  props: { className: 'container' },
  children: [
    { type: 'h1', props: {}, children: 'Hello React' },
    { type: 'p', props: {}, children: '虚拟DOM示例' }
  ]
}

嗯，其实就是个嵌套的对象。但它的威力在于：操作JS对象比操作真实DOM快得多。你想想看，JS对象在内存里，改它不需要浏览器做任何渲染工作。

核心思想：虚拟DOM把多次DOM操作合并成一次，通过批量更新减少真实DOM的访问次数。

我在项目中遇到过这样一个场景：一个表格组件，每行有十几个字段，用户批量编辑时数据变化特别频繁。如果用真实DOM，每次修改都直接操作DOM，页面卡得不行。改用虚拟DOM后，所有变更先在虚拟DOM上完成，最后一次性更新真实DOM，流畅多了。

2.2 Fiber架构：React 16的翻身仗

React 16之前，虚拟DOM的协调过程是同步递归的。什么意思？就是一旦开始更新，就得一口气干完，中间不能停。如果组件树很大，主线程就被一直占用，用户点击、输入都没反应。

我记得有个同事吐槽：「React 15的页面，数据一多就卡成PPT。」

Fiber架构就是为了解决这个问题。它把更新过程拆成一个个小任务，每个任务叫一个「Fiber节点」。这些节点可以中断、恢复、优先级排序。

个人习惯：我把Fiber理解成「可中断的工作单元」。每个Fiber节点对应一个组件实例，保存了它的状态、副作用、子节点等信息。

Fiber架构的核心是双缓冲机制。React维护了两棵Fiber树：

  • current树：当前屏幕上显示的内容
  • workInProgress树：正在构建的新内容

更新时，React在workInProgress树上工作。完成后，直接切换指针，workInProgress变成current。这个过程叫「提交」。

// Fiber节点的简化结构
const fiberNode = {
  tag: 'HostComponent',      // 节点类型
  key: 'item-1',             // 唯一标识
  stateNode: divElement,     // 对应的真实DOM
  child: fiberNodeChild,     // 第一个子节点
  sibling: fiberNodeSibling, // 下一个兄弟节点
  return: fiberNodeParent,   // 父节点
  pendingProps: {},          // 新属性
  memoizedProps: {},         // 旧属性
  effectTag: 'UPDATE',       // 副作用标记
  alternate: null            // 指向另一棵树对应节点
}

为什么要用链表结构？因为链表可以随时中断遍历。数组不行，你中断了下次还得从头来。链表可以记住当前节点，下次从这继续。

2.3 调度机制：谁先谁后？

有了Fiber节点，还得有个调度器来决定「先干哪个活」。React的调度器基于优先级来安排任务。

优先级分几档：

优先级 场景 说明
Immediate 用户输入、点击 最高优先级，必须立即响应
UserBlocking 滚动、悬停 用户能感知到的交互
Normal 网络请求、数据更新 普通更新
Low 分析、日志 可以延迟处理
Idle 预加载、缓存 空闲时才做

我曾经犯过一个错：在useEffect里直接调用了setState更新大量数据，结果页面卡死了。后来才知道，useEffect里的更新默认是Normal优先级，但如果用户正在输入，这个优先级会被打断，优先处理输入。

注意：React 18的并发模式进一步强化了调度能力。它允许React在渲染过程中「暂停」，去处理更高优先级的任务，然后再回来继续。

调度器的工作流程大致是：

  1. 任务进来，计算优先级
  2. 放入任务队列，按优先级排序
  3. 浏览器空闲时（通过requestIdleCallback或MessageChannel），取出最高优先级任务执行
  4. 执行一个Fiber节点后，检查是否有更高优先级任务插入
  5. 如果有，中断当前任务，处理高优先级任务
  6. 高优先级任务完成后，回来继续

说白了，这就是个「时间分片」的思路。把一整块时间切成小片，每片干一点活，中间留出空隙给浏览器处理用户交互。

2.4 协调与Diff算法：怎么比？

协调（Reconciliation）就是对比新旧两棵虚拟DOM树，找出差异的过程。而Diff算法是协调的核心。

React的Diff算法有三个策略，都是基于实际场景的优化：

  • 策略一：只对比同层节点，不跨层级比较。因为DOM节点跨层级移动的情况很少见。
  • 策略二：不同类型的节点直接替换。比如<div>变成<span>，直接干掉旧的，新建新的。
  • 策略三：同类型节点通过key来匹配。这是最常用的优化手段。

嗯，这里要重点说说key。我见过太多人用数组索引当key了，包括我自己早期也这么干过。

// ❌ 错误示范：用索引当key
{items.map((item, index) => <Item key={index} />)}

// ✅ 正确做法：用唯一id
{items.map(item => <Item key={item.id} />)}

为什么不能用索引？你想想看，如果数组中间插入或删除一项，所有后面的项索引都变了。React会认为所有项都变了，全部重新创建。性能差不说，还可能引发状态错乱。

我曾经在项目中用索引当key，结果列表的输入框内容全乱了。排查了半天才发现是key的问题。从那以后，我养成了习惯：只要列表会变化，一定用稳定且唯一的key。

Diff算法的具体流程：

  1. 对比新旧两个Fiber节点的类型
  2. 类型不同，直接替换（删除旧节点，创建新节点）
  3. 类型相同，更新属性
  4. 对比子节点列表，用key匹配
  5. 匹配上的复用，没匹配上的创建或删除
  6. 标记需要更新的节点（打上effectTag）

关键点：Diff算法的时间复杂度是O(n)，而不是O(n³)。这是React敢用虚拟DOM的底气所在。

2.5 从虚拟DOM到真实DOM的完整流程

把上面这些串起来，React的渲染流程就是：

  1. 触发更新：setState、useState的更新函数、forceUpdate等
  2. 调度阶段：计算优先级，放入任务队列
  3. 协调阶段：从根Fiber节点开始，深度优先遍历，构建workInProgress树
  4. Diff阶段：对比新旧Fiber节点，标记需要更新的节点
  5. 提交阶段：一次性把标记的更新应用到真实DOM上
  6. 生命周期：触发useEffect、componentDidMount等副作用

注意，第3步和第4步是可以中断的。只有第5步提交阶段是同步的，必须一口气完成。因为一旦开始修改真实DOM，就不能停，否则用户会看到半成品的界面。

避坑指南：我曾经在componentDidUpdate里又调了setState，导致无限循环。记住，提交阶段触发的生命周期里不要再触发更新，除非你加了条件判断。

最后说个我自己的体会：理解React渲染机制，不是为了背概念，而是为了写出更高效的代码。比如你知道Diff算法只对比同层节点，那你就应该尽量保持组件结构稳定，不要频繁改变DOM层级。你知道调度器会按优先级处理任务，那你就应该把用户交互相关的更新优先级提高。

说白了，React的渲染机制就是一套「用空间换时间」的优化方案。虚拟DOM占用了额外内存，但换来了更高效的更新。Fiber架构增加了复杂度，但换来了流畅的用户体验。值不值？我觉得值。

← 上一章 📖 返回目录 下一章 →