背景与动机：为什么需要 Fiber
摘要：本文是 React Fiber 架构全景解析系列的第一篇，从 Stack Reconciler 的性能瓶颈出发，讲解为什么 React 需要 Fiber 架构。包含浏览器渲染机制、递归与迭代的区别、Fiber 的核心目标等基础概念。
系列文章：
- 第一篇：背景与动机（本文）
- 第二篇：Fiber 数据结构与链表重构
- 第三篇：工作循环与渲染流程
- 第四篇：实战优化与性能监控
目录
一、核心概念铺垫 二、React 15 的架构局限 三、为什么需要 Fiber 四、从递归到迭代：架构重构
一、核心概念铺垫
在深入 Fiber 之前，我们需要理解几个关键概念：
1.1 什么是协调器（Reconciler）？
协调器是 React 的核心模块之一，负责：
- 比较新旧虚拟 DOM 树的差异（Diff 算法）
- 计算最小化的 DOM 更新操作
- 将更新应用到真实 DOM
简单来说，协调器就是 React 的"更新引擎"。
1.2 什么是递归？
递归是一种编程技巧，函数在执行过程中调用自身。
/**
* 递归示例：计算阶乘
* @param {number} n - 输入数字
* @returns {number} n 的阶乘
*/
function factorial(n) {
// 终止条件：n 等于 1 时返回 1
if (n === 1) {
return 1;
}
// 递归调用：n 乘以 (n-1) 的阶乘
return n * factorial(n - 1);
}
// 调用过程：
// factorial(5)
// = 5 * factorial(4)
// = 5 * 4 * factorial(3)
// = 5 * 4 * 3 * factorial(2)
// = 5 * 4 * 3 * 2 * factorial(1)
// = 5 * 4 * 3 * 2 * 1
// = 120
递归的特点：
- 代码简洁，逻辑清晰
- 一旦开始，必须执行到终止条件才能返回
- 无法中途暂停或中断
1.3 什么是迭代？
迭代是使用循环结构重复执行代码。
/**
* 迭代示例：计算阶乘
* @param {number} n - 输入数字
* @returns {number} n 的阶乘
*/
function factorial(n) {
// 初始化结果为 1
let result = 1;
// 循环从 1 到 n
for (let i = 1; i <= n; i++) {
// 每次循环将结果乘以 i
result = result * i;
// 可以在循环中检查条件，随时退出
if (result > 100) {
break; // 可以中途退出
}
}
return result;
}
迭代的特点：
- 可以中途暂停或退出
- 更适合需要控制执行进度的场景
- 代码可能稍复杂，但更灵活
1.4 浏览器渲染机制
要理解为什么同步更新会导致卡顿，需要了解浏览器的渲染流水线：
┌─────────────────────────────────────────────────────────┐
│ 浏览器主线程 │
├─────────────────────────────────────────────────────────┤
│ JavaScript 执行 │ 样式计算 │ 布局 │ 绘制 │ 合成 │
│ (React) │ (Style) │ (Layout)│ (Paint)│(Composite)│
└─────────────────────────────────────────────────────────┘
浏览器渲染流程说明：
- JavaScript 执行：运行 JS 代码，可能修改 DOM
- 样式计算：计算每个元素的最终样式
- 布局：计算每个元素的位置和大小
- 绘制：将元素绘制到图层上
- 合成：将多个图层合并显示到屏幕
浏览器以 60 FPS（每秒 60 帧）为目标，意味着每帧只有 16.67ms 的时间预算：
单帧时间分配（理想情况）：
┌────────────────────────────────────────┐
│ JS 执行 │ 样式 │ 布局 │ 绘制 │ 空闲 │
│ 5ms │ 2ms │ 2ms │ 3ms │ 4.67ms │
└────────────────────────────────────────┘
↑
React 更新应该在这个时间内完成
二、React 15 的架构局限（Stack Reconciler 问题）
在 React 15 及之前版本，React 使用 Stack Reconciler（栈协调器）进行虚拟 DOM 的 Diff 和更新。理解 Stack Reconciler 的局限，是理解 Fiber 架构必要性的前提。
2.1 Stack Reconciler 的工作方式
Stack Reconciler 的更新过程是同步且递归的。当组件状态发生变化时，React 会：
- 从根组件开始，递归遍历整棵组件树
- 对每个组件执行 Diff 算法，计算需要更新的 DOM 节点
- 同步应用所有 DOM 变更
代码示例 - React 15 风格的伪代码（同步递归更新）：
/**
* 挂载组件函数（React 15 风格）
* @param {HTMLElement} parent - 父 DOM 节点
* @param {Object} element - 虚拟 DOM 元素
* @returns {Object} 组件实例
*/
function mountComponent(parent, element) {
// 步骤 1：创建组件实例
// 根据元素的构造函数创建一个新的组件对象
const instance = new Component(element.props);
// 步骤 2：递归渲染子组件
// 调用组件的 render 方法获取子元素
const renderedElement = instance.render();
// 递归调用 mountComponent 处理子元素
// 注意：这里必须等子组件全部挂载完成才能继续
const childNode = mountComponent(parent, renderedElement);
// 步骤 3：将组件的 DOM 节点挂载到父节点
parent.appendChild(childNode);
// 返回组件实例供后续使用
return instance;
}
/**
* 更新组件函数（React 15 风格）
* @param {Object} instance - 组件实例
* @param {Object} newProps - 新的属性
*/
function updateComponent(instance, newProps) {
// 步骤 1：更新组件的 props
instance.props = newProps;
// 步骤 2：递归更新子组件
// 调用 render 获取新的子元素
const renderedElement = instance.render();
// 递归调用 updateComponent 更新子组件
// 注意：同步阻塞，必须等所有子组件更新完成
updateComponent(instance.child, renderedElement);
// 步骤 3：同步更新真实 DOM
updateDOM(instance.dom, renderedElement);
}
关键问题分析：
这段伪代码揭示了一个关键问题：递归调用是同步且不可中断的。一旦开始更新，必须一口气完成整棵树的遍历和更新，才能将控制权交还给浏览器。
调用栈示意图：
mountComponent()
└─ mountComponent() // 子组件 1
└─ mountComponent() // 子组件 1-1
└─ mountComponent() // 子组件 1-1-1
└─ ... // 必须全部完成才能返回
2.2 同步递归的性能瓶颈
让我们通过一个具体场景理解问题：
/**
* 商品列表组件
* @param {Array} products - 商品数组
*/
function ProductList({ products }) {
return (
<div>
{products.map(product => (
<ProductCard key={product.id} product={product} />
))}
</div>
);
}
/**
* 商品卡片组件（单个商品）
* @param {Object} product - 商品对象
*/
function ProductCard({ product }) {
return (
<div className="card">
<img src={product.image} alt={product.name} />
<h3>{product.name}</h3>
<p>{product.price}</p>
</div>
);
}
// 当用户搜索过滤时，触发全量重渲染
const filteredProducts = products.filter(p =>
p.name.includes(searchTerm)
);
setFilteredProducts(filteredProducts);
在 Stack Reconciler 下，这次状态更新会触发：
时间线（假设每组件 Diff 耗时 2ms）：
├─ ProductList (2ms) // 列表组件本身
├─ ProductCard[0] (2ms) // 第 1 个商品
├─ ProductCard[1] (2ms) // 第 2 个商品
├─ ProductCard[2] (2ms) // 第 3 个商品
...
├─ ProductCard[999] (2ms) // 第 1000 个商品
└─ 总耗时：约 2000ms = 2 秒
2 秒内，JavaScript 线程完全被 React 的递归更新占用，浏览器无法：
- 响应用户的点击、滚动、输入
- 执行动画
- 处理网络请求回调
- 进行垃圾回收
用户感知到的就是：页面卡顿、掉帧、无响应。
2.3 性能问题可视化
当 React 的同步更新超过 16.67ms 时：
实际发生的情况（React 更新耗时 100ms）：
┌────────────────────────────────────────────────────────┐
│ React JS 执行 (100ms) │ 掉帧 │ 掉帧 │ 掉帧 │ 掉帧 │
│ │ (1) │ (2) │ (3) │ (4) │
└────────────────────────────────────────────────────────┘
结果：用户看到 4-6 帧的卡顿，体验极差。
三、为什么需要 Fiber
基于上述问题，React 团队在 2017 年推出了 Fiber 架构（React 16），核心目标是：
将渲染任务拆分为可中断的小单元，让 React 能够与浏览器共享主线程控制权。
3.1 Fiber 的核心目标
1. 可中断的渲染（Interruptible Rendering）
- 将更新任务拆分为多个小单元（每个 Fiber 节点）
- 每个单元完成后，检查剩余时间
- 时间用完则暂停，将控制权交还浏览器
- 浏览器处理完高优先级任务后，React 恢复执行
2. 优先级调度（Priority Scheduling）
- 不同更新有不同优先级（用户输入 > 数据获取 > 动画）
- 高优先级任务可以打断低优先级任务
- 支持并发渲染（Concurrent Rendering）
3. 增量渲染（Incremental Rendering）
- 不必一次性完成整棵树更新
- 可以分批次、分阶段完成
- 支持 Suspense、useTransition 等并发特性
3.2 Fiber 架构示意图
传统树结构 vs Fiber 链表结构对比：
【传统虚拟 DOM 树（React 15）】
Root
/ | \
A B C
/ \ |
D E F
【Fiber 链表结构（React 16+）】
Root
│
↓
A ──→ B ──→ C
│ │
↓ ↓
D ──→ E F
遍历顺序（深度优先）：
1. Root → 2. A → 3. D → 4. E → 5. B → 6. C → 7. F
链表结构的优势：
-
每个节点显式记录：
child（第一个子节点）sibling（下一个兄弟节点）return（父节点）
-
可以通过循环遍历整棵树，无需递归调用栈
-
可以随时保存遍历进度（当前 Fiber 节点指针）
-
支持深度优先遍历的迭代实现
四、从递归到迭代：架构重构
Fiber 架构的本质是将递归算法改写为迭代算法：
/**
* Stack Reconciler（递归，不可中断）
* @param {Object} node - 虚拟 DOM 节点
*/
function renderRecursive(node) {
// 终止条件：节点为空则返回
if (!node) return;
// 处理当前节点（如创建 DOM、Diff 等）
processNode(node);
// 递归处理子节点（一旦开始，必须完成）
// 问题：无法中途暂停，必须等所有子节点处理完
node.children.forEach(child => renderRecursive(child));
}
/**
* Fiber Reconciler（迭代，可中断）
* @param {Object} rootFiber - Fiber 根节点
*/
function renderIterative(rootFiber) {
// 初始化当前节点指针
let currentFiber = rootFiber;
// 使用循环代替递归
while (currentFiber) {
// 处理当前节点
processFiber(currentFiber);
// 检查是否需要暂停（时间片用完）
if (shouldYield()) {
// 保存进度，返回
// 下次可以从 currentFiber 继续
return;
}
// 移动到下一个 Fiber 节点
currentFiber = getNextFiber(currentFiber);
}
}
关键区别对比：
| 特性 | 递归（Stack） | 迭代（Fiber） |
|---|---|---|
| 遍历方式 | 函数调用自身 | 循环 + 指针移动 |
| 进度管理 | 隐式（调用栈） | 显式（currentFiber 变量） |
| 可中断性 | ❌ 不可中断 | ✅ 可随时暂停 |
| 恢复机制 | 无法恢复 | 从指针位置继续 |
| 控制权 | 独占主线程 | 与浏览器共享 |
五、总结与下篇预告
5.1 本篇要点
- Stack Reconciler 的问题：同步递归导致主线程长时间阻塞
- 浏览器渲染机制：每帧只有 16.67ms，React 更新需要在这个时间内完成
- Fiber 的核心目标：可中断渲染、优先级调度、增量渲染
- 从递归到迭代：Fiber 架构的本质是算法重构
5.2 下篇预告
第二篇：Fiber 数据结构与链表重构
- Fiber 节点的完整定义（源码逐字段解析）
- 链表结构 vs 树结构的优劣对比
- 双缓冲机制（current vs workInProgress）
- 手写 mini-Fiber 实现
参考文献
- React 官方文档 - react.dev/
- React Fiber 架构 - github.com/acdlite/rea…
- React GitHub 仓库 - github.com/facebook/re…
版权声明：本文为原创技术文章，欢迎转载，请注明出处。
