使用过 React v16 之前版本的开发者或许都经历过这样的场景：当页面包含复杂组件或大量列表时，输入框打字会卡顿，滚动会不流畅。这些体验问题的背后，往往与 React 的渲染机制密切相关。2017 年 React v16 推出的 Fiber 架构，正是为解决这些核心问题而生。本文将系统解读 React 新架构的演进之路。

一、旧架构的性能瓶颈：为什么会卡顿？

在 Fiber 出现之前，React 使用的是基于栈的递归协调（Stack Reconciler）机制。这种架构在处理复杂组件树时，会暴露出难以克服的性能问题。

1.1 不可中断的同步更新

JavaScript 是单线程语言，浏览器的渲染（UI 绘制）和脚本执行共用一个主线程。Stack Reconciler 采用深度优先递归方式比对虚拟 DOM，这种方式有一个致命缺陷：一旦开始执行，就必须等到整个组件树处理完成才能释放主线程。

想象一个包含 1000 个项目的列表：React 会从根组件开始，逐层递归处理每个子组件，整个过程无法暂停。如果这个过程耗时超过 16ms（浏览器每秒刷新 60 帧的时间间隔），就会阻塞渲染，导致页面卡顿。用户输入、鼠标移动等交互事件也会因为主线程被占用而无法及时响应。

1.2 缺乏优先级区分

旧架构对所有更新一视同仁，无法区分任务的轻重缓急。例如：

• 用户正在输入搜索关键词（高优先级，需要即时反馈）
• 同时页面在后台加载并渲染搜索结果（低优先级）

在 Stack 架构中，这两个任务会抢占主线程，可能导致输入框响应延迟，严重影响用户体验。

1.3 递归调用栈的限制

递归调用会形成一个连续的调用栈，栈的深度与组件树的深度一致。当组件树层级较深时，不仅容易导致栈溢出错误，更重要的是：JavaScript 引擎无法在递归过程中暂停执行某部分任务。这种机制使得 React 无法灵活应对运行时的各种情况，比如中途插入高优先级任务。

二、Fiber 架构：如何解决这些问题？

Fiber 架构的设计初衷，就是要打破 Stack Reconciler 的限制，实现 “可控的渲染过程”。它不是简单的优化，而是一次底层架构的重构。

2.1 核心目标：实现可中断、可恢复的更新

Fiber 架构通过两大革新实现这一目标：

• 把渲染任务分解为小单元（每个单元对应一个组件的处理）
• 每个单元执行完成后，允许暂停、恢复甚至放弃执行

这样，React 可以在处理完一个小单元后检查：是否有更高优先级的任务需要处理？当前是否已经超过了浏览器的一帧时间？如果是，就先释放主线程，等下一次机会再继续执行。

2.2 数据结构革新：从递归树到链表

Fiber 用链表结构替代了递归调用栈，每个 Fiber 节点就是一个工作单元。每个节点包含三个关键指针：

• child：指向第一个子节点
• sibling：指向兄弟节点
• return：指向父节点

这种结构让 React 可以像 “遍历链表” 一样处理组件树，而不是依赖 JavaScript 引擎的调用栈。遍历过程可以随时暂停，因为当前进度可以通过这些指针被完整记录（比如 “当前处理到哪个节点，下一个该处理哪个节点”）。

// Fiber节点简化结构
const fiberNode = {type: 'div',        // 节点类型stateNode: domNode, // 对应的DOM节点child: null,        // 第一个子节点sibling: null,      // 兄弟节点return: null,       // 父节点// ...其他属性（优先级、更新队列等）
};

2.3 工作循环：分阶段处理任务

Fiber 架构将渲染过程分为两个阶段，实现了 “计算” 与 “执行” 的分离：

1. 调度阶段（Reconciliation）
   • 负责找出前后虚拟 DOM 的差异（Diffing）
   • 为需要更新的节点打上标记（新增、删除、修改）
   • 可被中断：如果有更高优先级任务，可以暂停当前计算
2. 提交阶段（Commit）
   • 根据调度阶段的标记，执行实际的 DOM 操作
   • 调用组件生命周期函数或 Hooks（如useEffect）
   • 不可中断：确保 DOM 操作的原子性，避免页面出现不一致状态

这种分离设计，让 React 可以在调度阶段灵活调整执行顺序，同时保证最终 DOM 更新的稳定性。

三、调度器（Scheduler）：让任务有轻重缓急

仅有 Fiber 结构还不够，还需要一个智能的调度系统来决定：什么时候该执行哪个任务？

3.1 优先级分级机制

React 调度器根据任务的紧急程度，将其分为不同优先级：

• Immediate：同步执行，最高优先级（如用户输入）
• UserBlocking：用户交互相关（如点击事件），需在 25ms 内完成
• Normal：普通更新（如网络请求后的渲染），500ms 内完成
• Low：低优先级任务（如列表预加载），1000ms 内完成
• Idle：空闲时执行（如日志上报），没有时间限制

3.2 时间切片（Time Slicing）

调度器利用浏览器的requestIdleCallback或setTimeout模拟时间切片，确保每个任务单元的执行不超过 5ms-10ms。每处理完一个单元，就检查是否超时或有更高优先级任务：

function workLoop() {// 只要有任务且未超时，就继续执行while (nextUnitOfWork && !shouldYield()) {nextUnitOfWork = performUnitOfWork(nextUnitOfWork);}
}// 判断是否需要让出主线程
function shouldYield() {return performance.now() >= deadline; // deadline是当前时间切片的截止时间
}

这种机制保证了主线程不会被长时间占用，浏览器有机会处理用户输入和渲染，从而避免卡顿。

四、双缓冲机制：提升渲染效率

Fiber 架构通过维护两棵树来优化渲染性能：

• current 树：当前显示在页面上的 Fiber 树，与 DOM 节点一一对应
• workInProgress 树：正在构建的新树，基于最新状态计算

当开始更新时，React 会以 current 树为基础，创建 workInProgress 树。对于不需要变更的节点，直接复用（通过alternate指针关联）；需要更新的节点，创建新的 Fiber 节点。全部计算完成后，只需将根节点的指针从 current 树切换到 workInProgress 树，就能完成一次高效的更新。

这种 “双缓冲” 策略避免了频繁创建和销毁节点的开销，同时确保了 DOM 更新的原子性（用户不会看到中间状态）。

五、新架构带来的开发模式变革

Fiber 架构不仅解决了性能问题，更为 React 引入了新的开发能力，这些能力在 React 18 中得到了全面强化。

5.1 并发更新（Concurrent Updates）

在并发模式下，React 可以同时准备多个版本的 UI（比如快速输入时的多个中间状态），但只提交最终版本。这使得应用能在复杂计算的同时保持响应性。

import { startTransition } from 'react';// 输入框实时搜索示例
function Search() {const [input, setInput] = useState('');const [results, setResults] = useState([]);function handleChange(e) {setInput(e.target.value);// 标记搜索结果更新为低优先级startTransition(() => {setResults(searchApi(e.target.value));});}return (<div><input value={input} onChange={handleChange} /><ResultsList results={results} /></div>);
}

startTransition告诉 React：输入框更新（setInput）是紧急的，而搜索结果更新（setResults）可以延迟，不会阻塞用户输入。

5.2 性能优化的最佳实践

基于新架构的特性，我们可以采用更精准的优化策略：

• 拆分组件：将大组件拆分为小组件，让任务单元更细，便于中断和恢复
• 使用React.memo：减少不必要的重渲染，尤其适合列表项组件
• 合理使用优先级 API：通过startTransition和useDeferredValue区分紧急与非紧急更新
• 虚拟滚动：对于超长列表，只渲染可视区域内的项

六、总结

Fiber 架构的意义远不止于性能提升，它代表了 React 设计理念的转变：

• 以用户体验为中心：优先保证交互响应速度，而非追求代码执行效率
• 增量计算思想：将复杂任务分解为可增量处理的单元，适应浏览器的工作机制
• 弹性设计：通过优先级和中断机制，让应用能灵活应对不同运行时环境