登录
React Fiber：从“递归地狱”到“时间切片”的重生之路
2025年10月22日 20:03
本文以风趣的笔调讲解 React Fiber 架构，结合代码与图示，深入解析 Fiber 的链表结构、三指针关系及可中断更新机制，帮助读者理解 React 如何实现高效的任务调度与渲染流程。
参考：《React 技术揭秘》 by 卡颂
一、前言：React，不只是“快”
React 团队做架构升级，从来不是为了单纯的“更快”。
如果只是性能，他们完全可以优化 reconciliation 算法或者 diff 策略。
他们真正追求的，是**“控制时间”**——
让 UI 的更新可被中断、调度、恢复，就像一位懂分寸的画家，
知道什么时候该收笔，什么时候该补色。
这正是 React Fiber 想要实现的哲学。
而理解它的钥匙，藏在一个看似“学术味”的概念里：
👉 代数效应（Algebraic Effects）
二、代数效应：一个让函数更“有礼貌”的思想
简单来说，代数效应解决的是一个老大难问题：
当一个函数既要保持纯净逻辑，又要处理副作用时，该怎么办？
我们先看一个极简例子👇
function getTotalPicNum(user1, user2) {
const picNum1 = getPicNum(user1);
const picNum2 = getPicNum(user2);
return picNum1 + picNum2;
}
逻辑简单到极致——加法而已。
但一旦 getPicNum 变成异步（比如去服务器查图片数），
整条函数调用链就被 async/await 感染了：
async function getTotalPicNum(user1, user2) {
const picNum1 = await getPicNum(user1);
const picNum2 = await getPicNum(user2);
return picNum1 + picNum2;
}
于是，你的整个项目从同步世界坠入了“Promise 地狱”。
这就像一场小感冒引发了全公司的核酸检测。
代数效应的思路是这样的：
副作用由外部捕获和恢复，函数内部依然保持纯净。
为了说明，我们用一段虚构语法来模拟它的思想（不是 JS 代码，只是概念演示）：
function getPicNum(name) {
const picNum = perform name; // 执行副作用
return picNum;
}
try {
getTotalPicNum('kaSong', 'xiaoMing');
} handle (who) {
switch (who) {
case 'kaSong':
resume with 230;
case 'xiaoMing':
resume with 122;
}
}
这里的 perform 会触发外层的 handle，resume 再将结果带回中断点继续执行。
也就是说，函数逻辑和副作用的执行被“分离”了。
听起来是不是有点像 React 的 “render” 与 “commit” 阶段？
三、Fiber 登场：React 的代数效应工程实现
React Fiber 是 React 团队为了解决同步递归更新无法中断的问题而重写的协调器。
换句话说，它是 React 的一次“灵魂重构”。
Fiber 的核心目标是：
- 支持任务分片与优先级调度
- 允许任务中断与恢复
- 恢复后能复用中间结果
或者更通俗点说：
以前 React 渲染是一口气吃完的火锅；
Fiber 让它可以夹一口肉，放下筷子接个电话，再回来继续吃。
🌿 Fiber 是什么？
Fiber（纤程）并不是 React 发明的词。
它早就出现在计算机领域中，与进程（Process）、线程（Thread）、协程（Coroutine）并列。
在 JavaScript 世界里，协程的实现是 Generator。
所以我们可以说：
Fiber 是 React 在 JS 里，用链表结构模拟协程的一种实现。
简单理解：
Fiber 就是一种可中断、可恢复的执行模型。
四、Fiber 节点结构：链表串起的「可中断栈」
Fiber 架构中，每个 React Element 对应一个 Fiber 节点，
每个 Fiber 节点都是一个「工作单元」。
结构大致如下👇
FiberNode {
type, // 对应组件类型
key, // key
return, // 父 Fiber
child, // 第一个子 Fiber
sibling, // 兄弟 Fiber
pendingProps, // 即将更新的 props
memoizedProps, // 已渲染的 props
stateNode, // 对应的 DOM 或 class 实例
}
它的核心是用链表结构，模拟函数调用栈。
这样 React 就能“暂停栈帧”，在浏览器空闲时恢复执行。
想象一个任务循环（伪代码）：
while (workInProgress && !shouldYield()) {
workInProgress = performUnitOfWork(workInProgress);
}
shouldYield() 会检测浏览器时间是否用完。
如果主线程要去干别的事（比如动画、用户输入），React 会体贴地暂停。
这，就是 React Fiber 的“可中断渲染”精髓。
五、那 Generator 呢？为什么不用它？
有人会问：
“Generator 不也能暂停和恢复吗？为什么 React 要造轮子？”
确实，Generator 曾经是候选方案。
但它的问题在于两点：
-
传染性太强：用过
yield的函数，整条调用链都得改。 - 上下文绑定太死：一旦被中断，就难以灵活恢复特定任务。
举个例子：
function* doWork(A, B, C) {
var x = doExpensiveWorkA(A);
yield;
var y = x + doExpensiveWorkB(B);
yield;
var z = y + doExpensiveWorkC(C);
return z;
}
如果任务中途被打断，或者来个更高优的任务插队，
那 x 和 y 的计算状态就乱套了。
而 Fiber 则通过链表结构，把中间状态封装在节点上，
可以安全暂停、恢复、复用。
六、Fiber 调度：React 的“任务分片大师”
React Fiber 的渲染过程分两阶段：
- Render 阶段（可中断） ：生成 Fiber 树，计算变更。
- Commit 阶段（不可中断） ：执行 DOM 操作，提交更新。
示意图如下：
Render(可中断) ----> Commit(同步)
↑ ↓
调度器控制 应用更新
这正是代数效应的工程化体现：
逻辑阶段（Render）可以被中断和恢复，
副作用阶段（Commit）则由系统集中处理。
七、Hooks：代数效应的另一种体现
再看看 Hook：
function App() {
const [count, setCount] = useState(0);
return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}
这里的 useState、useReducer 等 Hook，
其实也是代数效应思想的体现：
组件逻辑中不关心状态保存的机制，只管声明“我需要一个状态”。
React 内部帮你处理 Fiber 节点中的状态链表。
你只需关心「逻辑」而非「调度」，
就像写同步代码一样，优雅得让人上瘾。
八、图解：Fiber = 可恢复的调用栈
App
├── Header
│ └── Logo
├── Content
│ ├── List
│ └── Detail
└── Footer
Fiber 的结构类似于：
-
child指向第一个子节点； -
sibling指向兄弟节点； -
return指回父节点。
这让 React 能像遍历树一样遍历组件，
并随时暂停、恢复任务，而不丢上下文。
九、总结：React 的“时间魔法”
如果你把 React 比作魔术师，那 Fiber 就是它的魔杖。
它让 React 拥有了“操控时间”的能力：
- 可以让任务暂停，等浏览器忙完再继续；
- 可以按优先级执行任务（比如用户输入优先于动画）；
- 可以在恢复时复用中间状态，不浪费计算。
🎯 一句话总结：
React Fiber = 代数效应 + 调度器 + 状态复用
