React 架构的“代数效应”：从源码视角理解副作用的分离与恢复

各位下午好，欢迎来到今天的“代码解剖室”。

今天我们要聊的东西，可能会让你觉得有点“神经质”。想象一下，你正在做一顿大餐。你切菜（创建 Fiber 节点），你点火（开始渲染），你把肉扔进锅里（执行副作用）。突然，你的老岳母打电话来了：“喂，能不能来帮个忙？”

此时此刻，你的大脑（主线程）被强制暂停了。这顿饭怎么办？如果你按照传统的方式，你可能会大喊一声“我不干了！”，然后把满锅的肉扔掉，甚至把厨房烧了。这当然不是我们要的结局。

在 React 的世界里，它要做的是：把火关小，把锅盖上，把菜拿出来放进保温盒，跟岳母说“稍等五分钟，我这就来”。等挂了电话，它打开保温盒，继续刚才切到哪了，接着炒。

这就是 React 的核心灵魂——代数效应。

虽然这个词听起来像是在大学数学系的高级研讨会上（Algebraic Effects），但在 React 的源码里，它就是一套极其精妙的中断与恢复机制。今天，我们不聊 Hooks 怎么用，我们扒开 React 的底裤，去看看它是如何在不崩溃、不丢失状态的前提下，把“渲染”这个本来应该线性执行的任务，掰成了一块一块的。

准备好了吗？拿好你的解剖刀。

第一部分：为什么要搞“代数效应”？

在 React 出现之前，Web 开发就像是在修路。你有一堆 <div>，你希望它们根据数据发生变化。在传统的 DOM 操作中，如果你想更新页面，你得先删掉旧的，再画新的。这中间的间隙，用户能看到丑陋的闪烁。

React 说是：“我是声明式的，我不直接操作 DOM，我操作数据。”

这带来了一个问题：怎么把数据变成 DOM？

渲染过程本质上是一个函数执行过程：render(props) -> JSX -> DOM。

如果这是一个纯函数，那是最好的。但是 React 不是纯函数，它有副作用。比如，你点击一个按钮，不仅要更新状态，还要把焦点放到输入框里。这个“把焦点放上去”的动作，就是副作用。

当浏览器说“时间到了，你这个脚本跑太快了，我要去处理键盘事件了”时，React 怎么办？

如果是传统方式，React 的 render 函数被中断了，就像你切菜切到一半，手被砍了一刀。那之前的计算（构建虚拟 DOM 树）全白费了。

React 的设计师们脑洞大开：为什么不允许函数被“暂停”？

这就是代数效应。它不关心“中断”是怎么发生的（可能是浏览器时间片到了，可能是网络请求挂起了），它只关心两件事：

1. 怎么暂停？（把现场保存下来）
2. 怎么恢复？（把现场读出来继续干）

这就引出了 React 最核心的数据结构——Fiber。

第二部分：Fiber —— 不，它不是棉花，它是栈帧

在 React 15 之前，React 就像一个只有一条腿的独行者，它是一个递归函数。

function renderRoot() {
  let currentFiber = workInProgress;
  while (currentFiber) {
    // 1. 创建子节点
    createChildFiber(currentFiber);
    // 2. 执行副作用
    executeSideEffects(currentFiber);
    // 3. 处理兄弟节点
    currentFiber = currentFiber.sibling;
  }
}

这种写法简单粗暴，但它有个致命缺陷：没有层级概念。你没法在渲染到第三层的时候，回头去修改第一层。一旦中断，整个树就断了，而且由于 JavaScript 的调用栈特性，很难保存每个节点的独立状态。

于是，React 16 诞生了 Fiber。

Fiber 的设计哲学是：把 React 的渲染过程变成了一个遍历链表的过程，而不是递归函数调用。

每一个 Fiber 节点，本质上就是一个栈帧。它记录了这一层组件的所有信息：当前的 props，状态，以及它“挂断”的时候在哪里。

// 源码视角的伪代码
class FiberNode {
  constructor(tag, props, stateNode) {
    this.tag = tag; // 函数组件、类组件、宿主组件...
    this.props = props;
    this.stateNode = null; // 指向真实的 DOM 节点

    // 关键：指向兄弟、子节点、父节点的指针
    this.return = null;
    this.child = null;
    this.sibling = null;

    // 指向这个节点对应的 WorkInProgress 节点（正在渲染的版本）
    this.alternate = null;

    // 状态更新
    this.pendingProps = null;
    this.memoizedProps = null;
    this.memoizedState = null;
  }
}

现在，我们的渲染器不再是调用函数，而是像走迷宫一样遍历这个链表。

第三部分：中断的艺术——从源码看 stackFrameList

既然是遍历链表，那中断就容易多了。就像你读一本书，读到了第 100 页，电话响了。你只需要记下“读到了第 100 页，第 3 段的第 5 行”，然后放下书，接电话。

React 在源码里把这个“记下在哪一行”的过程，叫做 stackFrameList（或者更准确地说是中断状态存储）。

在 React 的调度器中，当时间片耗尽时，会触发一个回调。这个回调会告诉渲染器：“兄弟，别干了，休息一下。”

此时，渲染器（Renderer）会调用 workLoop 函数，而这个函数的核心逻辑如下：

function workLoop(deadline) {
  // 如果还没到时间片结束，或者还有工作要做
  while (deadline.timeRemaining() > 0 && workInProgress) {
    // 核心任务：执行一个单元的工作
    performUnitOfWork(workInProgress);
  }

  // 如果时间片用完了，或者任务做完了
  if (workInProgress) {
    // 关键步骤：把当前的工作状态“压栈”
    // 告诉调度器：“我停在这儿了，下次来接着这搞”
    requestIdleCallback(workLoop);
  } else {
    // 任务彻底完成了
    commitRoot();
  }
}

看看 performUnitOfWork 做了什么。这可是重头戏，它是代数效应的具体落地。

function performUnitOfWork(fiber) {
  // 1. 创建子节点
  if (!fiber.child) {
    fiber.child = createChildFiber(fiber);
  }

  // 2. 处理副作用 (Render 阶段)
  if (fiber.effectTag) {
    scheduleEffect(fiber.effectTag);
  }

  // 3. 如果有子节点，就去处理子节点
  if (fiber.child) {
    return fiber.child;
  }

  // 4. 如果没有子节点，处理兄弟节点
  let nextFiber = fiber;
  while (nextFiber) {
    // 处理兄弟节点
    if (nextFiber.sibling) {
      return nextFiber.sibling;
    }
    // 处理完兄弟，回到父节点
    nextFiber = nextFiber.return;
  }
}

请注意上面的注释。这就是所谓的“栈帧”结构。
当 performUnitOfWork 遇到 return 时，它实际上是在告诉 React：“我处理完了当前节点，下一个请求回来的时候，从 nextFiber 或者 return 开始。”

这里有一个非常关键的概念：interruptedWork。

在源码中，全局（或者作为上下文传递）会有一个变量 interruptedWork。当渲染被中断时，React 会做如下操作：

1. 保存现场：把当前正在处理的 workInProgress 节点，以及它所有后续的兄弟节点和子节点树，挂载到 interruptedWork 上。
2. 重置状态：清空当前的 workInProgress 链表。

这意味着，React 在内存里保留了一份“未完成的草图”。下次浏览器说“我有空了”，React 再次调用 workLoop，它会立刻检查 interruptedWork。如果存在，它就把这个草图接回来，从断掉的地方继续画。

// 恢复时的伪代码
function workLoop(deadline) {
  if (interruptedWork) {
    // 哟，上次的活儿没干完啊？行，接着干
    workInProgress = interruptedWork;
    interruptedWork = null; // 恢复完就清空，准备新任务
  }

  // ... 后续逻辑同上
}

这就像是一个健忘的大厨，每次炒完菜，都会把剩下的菜切成块，贴个标签“下一顿接着炒”。

第四部分：副作用的分离——渲染 vs 提交

React 将渲染过程分为两个截然不同的阶段：渲染阶段 和 提交阶段。

渲染阶段（Render Phase）的目标是计算结果。它会递归地遍历 Fiber 树，计算新的状态，构建新的虚拟 DOM 结构。在这个过程中，React 不应该做任何真实的 DOM 操作，甚至连 console.log 都应该非常小心。

为什么？因为渲染阶段可能会被无限次中断！如果它触发了 DOM 操作，一旦中断，DOM 就会被修改一半，下次恢复时，DOM 就会处于一种“精神分裂”的状态。

提交阶段（Commit Phase）的目标是更新视图。这是真正“干活”的时候。

这里就体现了代数效应的另一个威力：副作用隔离。

想象一下，你在渲染阶段遇到一个 useLayoutEffect。

1. 你发现这是一个副作用。
2. 你把它记录在 fiber.effectTag 里。
3. 你并没有执行它！
4. 继续去处理下一个兄弟节点，或者返回父节点。

当渲染阶段彻底结束，所有的计算都完成了，React 才会进入提交阶段。此时，它会遍历所有带有 effectTag 的 Fiber 节点，然后依次执行这些副作用。

function commitRoot() {
  // 1. 先把 DOM 插入到页面（如果是首次渲染）
  commitAllHostEffects();

  // 2. 再执行 useLayoutEffect (在浏览器重绘之前)
  commitAllLayoutEffects();

  // 3. 最后执行 useEffect (在浏览器重绘之后)
  commitAllPassiveEffects();
}

这种分离让 React 能够从容地处理中断。即使你在渲染阶段被切断了，提交阶段也不会知道，因为提交阶段只在渲染阶段成功完成后才会触发。中断发生时，React 就像把一台正在高速运转的机器拆成了零件，分批装箱。等装配好了，再重新组装起来。

第五部分：实战演练——Suspense 与 挂起状态

说了这么多理论，我们来看看最酷的例子——Suspense。

当你使用 React.Suspense 包裹一个组件，并且这个组件内部使用了 useResource（比如一个读取数据的钩子），React 就进入了一个代数效应的高阶玩法。

假设你的组件代码长这样：

function Profile({ userId }) {
  // 这是一个代数效应的触发点
  const user = useResource(fetchUser(userId));

  if (user.status === 'pending') {
    return <LoadingSpinner />;
  }

  return <div>{user.data.name}</div>;
}

当 fetchUser 返回一个 Promise（它是可中断的），React 就会捕获这个异步操作。

过程模拟：

1. 触发中断：React 开始渲染 Profile。它计算了 props，准备渲染。它执行 useResource，发现这是个 Promise。此时，React 不会傻傻地等待 Promise 完成（那样会阻塞主线程，失去时间切片优势）。React 会抛出一个特殊的异常，这个异常不是错误，而是挂起状态。
2. 保存现场：就像前面说的，React 会保存当前的 workInProgress 树。它知道“我正在渲染 Profile 组件”。
3. 返回后备 UI：React 遇到挂起，它不会崩溃，而是根据 Suspense 的 fallback prop，渲染一个 <LoadingSpinner />。这棵新的树（包含 Spinner）会被渲染到屏幕上。
4. 切换 Context：React 会切换 Fiber 树的上下文，假装 Profile 组件不存在了，现在的根节点就是 LoadingSpinner。
5. 等待：浏览器继续调度。React 可能去处理别的点击事件。
6. 恢复：过了一会儿，fetchUser 返回了数据。Promise resolve 了。React 的调度器再次被唤醒。
7. 再次尝试：React 再次尝试渲染 Profile。
8. 成功：这次 useResource 不再抛出挂起异常，而是直接返回数据。渲染继续。React 发现 LoadingSpinner 不再需要了（因为 Profile 渲染出来了），它会删除 Spinner，把 Profile 挂上去。

这就是代数效应的魔法： 即使组件正在渲染（或者被中断），当外部条件改变（数据回来了），渲染可以无缝地恢复，中间的等待过程完全透明，甚至不需要你写任何 try/catch 代码。

第六部分：清理与副作用——为什么不需要 try/finally？

在传统的同步代码里，如果你要确保资源释放，你得写：

try {
  // 做一些事情
} finally {
  // 清理
}

但在 React 的 Fiber 栈里，为什么我们不需要在每个 Fiber 节点写 finally 块？

因为 Fiber 树本身就是一种“可恢复的链表”。当渲染中断时，React 会自动“遗忘”中断前的状态。当渲染恢复时，它从头开始构建一棵全新的树。

这种机制有一个副作用（或者叫特性）：副作用必须是无状态的。

如果某个副作用依赖于渲染过程的状态，那么当渲染中断并恢复时，这个状态可能就不存在了，或者逻辑会出错。

但 React 保证了：

1. 渲染阶段（Render Phase）只读，不写。它只构建数据结构，不修改真实 DOM。所以不用担心“修了一半 DOM”的问题。
2. 提交阶段（Commit Phase）一次性完成。既然是一次性的，就不需要 try/finally 来回滚。

这就像你在画画。渲染阶段是在心里打草稿（画在脑子里，不留下痕迹）。提交阶段才是往纸上涂颜料。如果画到一半电话响了，React 会把草稿收起来，等会儿接着画草稿。等草稿画好了，直接往纸上描，不需要“撤销”。

第七部分：深度源码剖析——interruptedRender 和 interruptedRoot

让我们更深入地看一下 React 源码中的细节。

在 ReactFiberRoot.js 中，有一个全局变量 interruptedRender。

// 简化版
let interruptedRender = null;

function renderRoot(root) {
  let subtree = null;

  do {
    // 1. 开始渲染
    subtree = workLoopSync(); // 同步渲染一帧

    // 2. 如果返回了 null，说明这一帧完了，看时间片
    if (subtree === null) {
      // 如果有中断残留，恢复它
      if (interruptedRender) {
        // 命中！上次停在这里，继续干
        subtree = interruptedRender;
        interruptedRender = null;
      } else {
        // 没有中断，彻底结束了
        return null;
      }
    }
  } while (true);

  return subtree;
}

这种写法非常像游戏引擎的循环。每帧渲染，如果没干完，就记下来，下一帧接着干。

当你看到 ReactDevTools 里的那个黄色的圆点在闪烁，或者你在 Chrome 的 Performance 面板里看到 React 的任务被切分成了一个个小块，那就是代数效应在底层疯狂运作的证明。

第八部分：未来展望——并发模式的真正含义

React 中的“并发”，本质上就是控制流的控制。

传统编程是“单线程顺序执行”。
并发模式（在 React 中）是“多线程并行执行”（模拟）。

我们通过 Fiber 架构模拟了多线程的上下文切换。
通过代数效应，我们模拟了进程的挂起和恢复。

这带来了什么？

1. 高优先级任务插队：如果用户点击了一个按钮（高优先级），React 可以立刻中止当前的渲染任务，把优先级最高的任务插到队首。因为渲染任务已经被打碎了，中断它非常 cheap。
2. 自动回滚：如果渲染过程中发生错误（或者被 Suspense 挂起），React 会自动回滚到上一个已提交的状态，而不是展示一个破碎的界面。

结语（彩蛋）

所以，下次当你看到那个复杂的 workInProgress 树，或者在源码里看到那一堆关于 interruptedWork 的判断时，不要觉得枯燥。

你要想象一下，那个巨大的、复杂的 React 内部世界，其实就像是一个在刀尖上跳舞的杂技演员。他手里拿着一根长长的杆子（Fiber 树），在空中表演。

当观众（浏览器）给他的时间不够了（时间切片），他必须立刻把杆子放下，做一个空中转体，稳稳地落地，把杆子插在地上（保存现场），然后等你喊“再来一次”的时候，他再拿起杆子，从刚才断的地方继续飞。

这就是 React 的代数效应。它把“副作用”从“渲染逻辑”中剥离出来，用一种极其优雅（虽然源码看起来有点乱）的方式，解决了 Web 界面并发更新的世界级难题。

好了，今天的讲座就到这里。如果你觉得理解了，记得去给 React 的作者们点个赞；如果你觉得没听懂，那就再去读一遍源码里的 workLoop 函数，这次带点感情读。

下课！