React 中的代数效应：从概念到 Fiber 架构的落地

参考：《React 技术揭秘》 by 卡颂

一、前言：React，不只是"快"

React 团队做架构升级，从来不是为了单纯的"更快"。

如果只是性能，他们完全可以优化 reconciliation 算法或者 diff 策略。

他们真正追求的，是**"控制时间"**------

让 UI 的更新可被中断、调度、恢复，就像一位懂分寸的画家，

知道什么时候该收笔，什么时候该补色。

这正是 React Fiber 想要实现的哲学。

而理解它的钥匙，藏在一个看似"学术味"的概念里：

👉 代数效应（Algebraic Effects）

二、代数效应：一个让函数更"有礼貌"的思想

简单来说，代数效应解决的是一个老大难问题：

当一个函数既要保持纯净逻辑，又要处理副作用时，该怎么办？

我们先看一个极简例子👇

ini 复制代码

function getTotalPicNum(user1, user2) {
  const picNum1 = getPicNum(user1);
  const picNum2 = getPicNum(user2);
  return picNum1 + picNum2;
}

逻辑简单到极致------加法而已。

但一旦 getPicNum 变成异步（比如去服务器查图片数），

整条函数调用链就被 async/await 感染了：

javascript 复制代码

async function getTotalPicNum(user1, user2) {
  const picNum1 = await getPicNum(user1);
  const picNum2 = await getPicNum(user2);
  return picNum1 + picNum2;
}

于是，你的整个项目从同步世界坠入了"Promise 地狱"。

这就像一场小感冒引发了全公司的核酸检测。

代数效应的思路是这样的：

副作用由外部捕获和恢复，函数内部依然保持纯净。

为了说明，我们用一段虚构语法来模拟它的思想（不是 JS 代码，只是概念演示）：

javascript 复制代码

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 节点都是一个「工作单元」。

结构大致如下👇

go 复制代码

FiberNode {
  type,          // 对应组件类型
  key,           // key
  return,        // 父 Fiber
  child,         // 第一个子 Fiber
  sibling,       // 兄弟 Fiber
  pendingProps,  // 即将更新的 props
  memoizedProps, // 已渲染的 props
  stateNode,     // 对应的 DOM 或 class 实例
}

它的核心是用链表结构，模拟函数调用栈 。

这样 React 就能"暂停栈帧"，在浏览器空闲时恢复执行。

想象一个任务循环（伪代码）：

ini 复制代码

while (workInProgress && !shouldYield()) {
  workInProgress = performUnitOfWork(workInProgress);
}

shouldYield() 会检测浏览器时间是否用完。

如果主线程要去干别的事（比如动画、用户输入），React 会体贴地暂停。

这，就是 React Fiber 的"可中断渲染"精髓。

五、那 Generator 呢？为什么不用它？

有人会问：

"Generator 不也能暂停和恢复吗？为什么 React 要造轮子？"

确实，Generator 曾经是候选方案。

但它的问题在于两点：

传染性太强 ：用过 yield 的函数，整条调用链都得改。
上下文绑定太死：一旦被中断，就难以灵活恢复特定任务。

举个例子：

ini 复制代码

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 操作，提交更新。

示意图如下：

scss 复制代码

Render(可中断) ----> Commit(同步)
     ↑                    ↓
   调度器控制         应用更新

这正是代数效应的工程化体现：

逻辑阶段（Render）可以被中断和恢复，

副作用阶段（Commit）则由系统集中处理。

七、Hooks：代数效应的另一种体现

再看看 Hook：

scss 复制代码

function App() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}

这里的 useState、useReducer 等 Hook，

其实也是代数效应思想的体现：

组件逻辑中不关心状态保存的机制，只管声明"我需要一个状态"。

React 内部帮你处理 Fiber 节点中的状态链表。

你只需关心「逻辑」而非「调度」，

就像写同步代码一样，优雅得让人上瘾。

八、图解：Fiber = 可恢复的调用栈

css 复制代码

App
 ├── Header
 │    └── Logo
 ├── Content
 │    ├── List
 │    └── Detail
 └── Footer

Fiber 的结构类似于：

child 指向第一个子节点；
sibling 指向兄弟节点；
return 指回父节点。

这让 React 能像遍历树一样遍历组件，

并随时暂停、恢复任务，而不丢上下文。

九、总结：React 的"时间魔法"

如果你把 React 比作魔术师，那 Fiber 就是它的魔杖。

它让 React 拥有了"操控时间"的能力：

可以让任务暂停，等浏览器忙完再继续；
可以按优先级执行任务（比如用户输入优先于动画）；
可以在恢复时复用中间状态，不浪费计算。

🎯 一句话总结：

React Fiber = 代数效应 + 调度器 + 状态复用