React 并发模式下的状态一致性：源码解析 prepareFreshStack 如何在重试渲染前清理全局状态栈

各位好！欢迎来到今天的“React 内核深潜”讲座。

咱们都知道，React 最近搞了个“并发模式”，听起来挺高大上，对吧？就像是给 React 装了个涡轮增压，跑得飞快。但是，各位大佬们，你们有没有想过，当你正在用 React 开发一个复杂的电商大促页面，突然后台弹出一个“新用户注册”的高优先级任务时，React 是怎么处理的？

这时候，React 就像是一个同时要应付三个老板的实习生。老板A让你写代码，老板B让你收快递，老板C突然插嘴让你去泡咖啡。如果你没有脑子，你就会把老板A的代码写了一半，然后跑去泡咖啡，最后老板C让你重写代码，结果你把老板A的代码全忘光了，只记得泡咖啡。

这就是并发模式下的状态一致性问题。

而在 React 的源码世界里，为了解决这个“实习生发疯”的问题，它发明了一个极其精密的机制，其中就有一个不起眼但至关重要的函数——prepareFreshStack。今天，我们就来扒开它的外衣，看看它到底是怎么在重试渲染前，把那个乱七八糟的“全局状态栈”清理得一干二净的。

准备好了吗？我们要开始“洗脑”了。不，我是说“深入浅出”。

第一部分：当渲染被打断，世界会怎样？

首先，咱们得理解什么是“渲染阶段”和“提交阶段”。

想象一下，你在写一个组件 UserList。它渲染了 100 个用户。这是一个低优先级的任务，就像是在公园里散步。React 正在慢慢地遍历这 100 个用户，计算 DOM 节点。

就在这时候，用户点击了“刷新页面”或者是一个弹窗组件 Modal 跳了出来。这是一个高优先级任务，就像是一辆法拉利突然冲进了公园。

React 说：“停！低优先级任务暂停，法拉利先上！”

React 会立刻挂起 UserList 的渲染，去处理 Modal。Modal 渲染完了，提交了，然后 React 回过头来：“好了，现在继续散步吧。”

问题来了：UserList 之前的状态还在吗？

如果你没有处理好，React 可能会记错 UserList 的状态。比如，它可能以为第一个用户的状态还是 loading，但实际上在渲染到第 50 个的时候，那个状态已经变成了 success。如果这时候直接重用旧的状态栈，就会导致状态错乱，界面就崩了。

为了防止这种“记忆错乱”，React 需要一种机制，在它决定“继续渲染”或者“重新渲染”之前，把之前所有的状态痕迹都擦掉，就像在考试前把桌子擦干净一样。

这个擦桌子的动作，就是 prepareFreshStack 的核心工作。

第二部分：栈——React 的记忆宫殿

在深入代码之前，咱们得先聊聊“栈”。

在计算机科学里，栈是一种后进先出（LIFO）的数据结构。React 的内核里充满了栈。为什么？因为它要处理组件的嵌套关系。

当你渲染一个组件树：

function App() {
  return (
    <Parent>
      <Child />
    </Parent>
  );
}

React 会在内存里压入栈帧。

1. 压入 App。
2. 压入 Parent。
3. 压入 Child。

当 Child 渲染完，它就出栈了。
当 Parent 渲染完，它也出栈了。

但是，在并发模式下，这个出栈过程可能会被打断。React 需要在栈里保存一些“快照”，以便后续恢复。

这里涉及到两个关键的概念：

1. Current Fiber Tree（当前树）：这是已经提交到屏幕上的那一棵树，它是稳定的。
2. WorkInProgress Fiber Tree（正在构建的树）：这是 React 正在脑子里画的新树，还没提交。

prepareFreshStack 的作用，就是在开始构建新的 WorkInProgress 树之前，确保这个“正在构建”的栈是干净的，或者说是“新鲜”的。

第三部分：源码探秘——renderWithHooks 中的 prepareFreshStack

在 React 的源码中，prepareFreshStack 这个名字其实更多出现在 Fiber 架构的早期思考或者特定的实现细节中。但在现在的 Fiber 实现里，它的核心逻辑主要分布在 renderWithHooks 函数中，特别是 prepareHooks 这个辅助函数里。

让我们假装自己是个黑客，潜入 React 的源码库。

当 React 决定开始一次新的渲染循环时，它会调用 renderWithHooks。这个函数就像是总指挥官。

// ReactFiberHooks.js (伪代码示意)
function renderWithHooks(
  current,
  workInProgress,
  Component,
  props,
  secondArg
) {
  // 1. 准备新鲜栈！这是关键步骤。
  prepareFreshStack(current, workInProgress);

  // 2. 执行组件函数
  let children = Component(props, secondArg);

  // 3. 后续处理...
  return children;
}

那么，prepareFreshStack 到底干了什么？让我们来看看它的具体实现逻辑（为了方便理解，我重写了 React 的一部分核心逻辑）：

function prepareFreshStack(current, workInProgress) {
  // 初始化 Hooks 栈光标
  // 这就好比给 React 一个新的笔记本，用来记录当前正在渲染的组件的 Hooks 状态
  workInProgressStackCursor.push(workInProgress, current);

  // 重置全局 Hooks 状态
  // 这一步非常关键。它告诉 React：“嘿，我们开始新的渲染了，之前的旧状态别再拿来用了！”
  renderDidSuspend = false;
  renderDidSuspendWithNoFallback = false;
  didTimeout = false;

  // 重置当前正在执行的 Hook 索引
  // 就像把书翻回第一页，准备重新读一遍
  currentlyRenderingFiber = workInProgress;

  // 初始化 Hooks 队列
  workInProgress.memoizedState = null;
  workInProgress.updateQueue = null;
  workInProgress.next = null;

  // ... 更多重置逻辑
}

这段代码看起来很枯燥，但咱们来翻译一下：

1. workInProgressStackCursor.push：这是在建立一个新的“栈”。React 使用栈光标来追踪当前正在渲染的组件的 current 状态。这确保了如果你在渲染 ComponentA 时，它的 useState 返回了旧值，那么当你切换到渲染 ComponentB 时，ComponentA 的栈会被压到底部，不会干扰 ComponentB。
2. 重置 renderDidSuspend：这个标志位告诉 React，我们这次渲染还没有挂起。如果之前挂起过，我们需要重新开始。

第四部分：实战演练——一个“幽灵”状态的诞生

为了让你明白为什么需要这个清理过程，咱们来写一个会出错的例子。

假设我们有一个组件 SuspenseList，它里面包含一个 HeavyComponent。HeavyComponent 需要加载数据。

function HeavyComponent() {
  const [data, setData] = useState(null);

  useEffect(() => {
    console.log("开始加载数据...");
    // 模拟耗时操作
    setTimeout(() => {
      setData("Data Loaded!");
    }, 5000);
  }, []);

  if (!data) {
    throw new Promise(() => {}); // 模拟 Suspense 挂起
  }

  return <div>{data}</div>;
}

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <HeavyComponent />
    </Suspense>
  );
}

场景重现：

1. React 开始渲染 App。
2. React 进入 HeavyComponent。
3. HeavyComponent 执行 useEffect，启动了 5 秒的定时器。
4. 关键点来了：在 5 秒钟内，用户点击了“刷新”，或者触发了某个高优先级更新。
5. React 决定中断 HeavyComponent 的渲染，去处理其他事情。

这时候，HeavyComponent 的状态栈里是什么样的？它知道数据还没加载完，所以它抛出了一个 Promise。

当 React 决定重试渲染 HeavyComponent 时，它必须调用 prepareFreshStack。

如果 React 没有调用 prepareFreshStack，会发生什么？
React 可能会直接复用之前的 workInProgress 节点。那个节点的 memoizedState 可能还是 null（因为还没加载完）。React 会认为：“哦，这个状态没变，不用重新计算了。”

结果就是，即使数据加载完成了，界面也不会更新，因为 React 还在用“旧的记忆”在骗自己。

通过 prepareFreshStack，React 强制重新执行 HeavyComponent 的逻辑：

1. useState 被重新调用。
2. useEffect 被重新检查（React 会判断是否需要重新执行，这涉及到 updateEffect 的逻辑，但至少它给了组件一个重新评估的机会）。
3. 状态栈被清空，重新构建。

第五部分：深入 renderDidSuspend —— 重试的开关

prepareFreshStack 的另一个重要功能是与 renderDidSuspend 交互。

在并发模式下，渲染不是一次性的。React 会尝试渲染。如果遇到了 Suspense 边界（比如上面的 HeavyComponent），它会调用 renderDidSuspend。

function renderDidSuspend() {
  renderDidSuspend = true;
  // 标记当前渲染树为“需要重试”的状态
}

当 prepareFreshStack 被调用时，它会重置这个标志位。

function prepareFreshStack(current, workInProgress) {
  // ...
  renderDidSuspend = false;
  // ...
}

这就好比是一个“重新开始”按钮。每次我们准备开始一次新的渲染（无论是首次渲染、中断后的重试，还是因为上下文变化而重新渲染），我们都会重置这个标志位。

代码示例：重试循环

React 的调度器（Scheduler）在后台会不断轮询，看是否有任务可以执行。

function workLoop() {
  // 1. 检查是否还有任务
  if (hasMoreWork) {
    // 2. 开始渲染
    renderWithHooks(current, workInProgress, Component, props);

    // 3. 检查渲染是否挂起
    if (renderDidSuspend) {
      // 4. 如果挂起了，React 会把当前状态保存起来，然后暂停
      // 此时 prepareFreshStack 已经在 renderWithHooks 内部执行过了，
      // 它清理了栈，保存了快照，确保下次重试时不会混乱。
      scheduleDeferredCallback(workLoop); // 延迟重试
      return;
    }

    // 5. 如果没挂起，说明渲染完成了
    completeUnitOfWork(workInProgress);
  }
}

你看，prepareFreshStack 就是在第 2 步和第 4 步之间那个微妙的间隙里工作的。它确保了当你从第 4 步（暂停）跳回第 2 步（重试）时，你的环境是全新的。

第六部分：resetHooksState —— 更细致的清理

有时候，prepareFreshStack 的清理还不够细致。我们可能需要更细粒度的控制，比如重置特定的 Hooks。

这就是 resetHooksState 登场的时候了。虽然 prepareFreshStack 是宏观的清理，但 resetHooksState 往往在 Fiber 节点更新时被调用。

当 React 决定更新一个已经存在的 workInProgress 节点时（而不是创建一个全新的节点），它需要确保这个节点的 Hooks 状态是正确的。

function resetHooksState() {
  currentlyRenderingFiber = currentlyRenderingFiber.alternate || currentlyRenderingFiber;

  // 这里的逻辑稍微有点绕，咱们简化一下：
  // 它会根据 current（旧树）的状态，来决定 workInProgress（新树）的状态是保持不变，
  // 还是重新初始化。
}

为什么这很重要？
想象一下，你在渲染组件 A。组件 A 里面有个状态 count，当前是 5。
你中断了。
然后你渲染组件 B。
现在你回来渲染组件 A。

如果 prepareFreshStack 做得太彻底，把 count 也清空了，那组件 A 的 UI 就会瞬间重置。这显然不对。组件 A 应该保留它当前的视觉状态，直到它真正被更新。

所以，prepareFreshStack 主要是为了清理“未完成”的中间状态，而 resetHooksState 则是负责维护“已完成”的视觉状态。

第七部分：全局状态栈的“防弹衣”

React 的全局状态栈（主要是 workInProgressStackCursor 和相关的上下文管理），在并发模式下就像是一件防弹衣。

当高优先级任务进来时，它会刺穿低优先级任务的栈。如果没有 prepareFreshStack 这层防护，低优先级任务的状态栈就会被高优先级任务的垃圾数据填满。

举个不恰当的比喻：
你正在写一封长邮件（低优先级）。
突然老板让你做一个 PPT（高优先级）。
如果没有 prepareFreshStack：
你打开 Word 写 PPT。
然后老板让你删掉 PPT，重新做一个。
你回到 Word，发现你刚才写的邮件内容全没了，或者变成了乱码，因为 Word 的内存被 PPT 占用了。

有了 prepareFreshStack：
你回到 Word，它自动保存了邮件的草稿（状态一致性），然后清空了屏幕上的光标位置（准备重新渲染）。
你开始重写 PPT。
一切都井井有条。

第八部分：源码中的“脏活累活”

让我们再稍微深入一点，看看 prepareFreshStack 在 Fiber 架构下是如何与 StackCursor 配合的。

// ReactFiberStack.js
let stackCursor = {
  current: null
};

function push(stack, value) {
  stack.push(value);
}

function pop(stack) {
  return stack.pop();
}

// 在 renderWithHooks 中
function renderWithHooks(...) {
  // 1. 保存当前的栈状态（为了防止递归）
  const prevStackCursor = stackCursor.current;

  // 2. 准备新鲜栈
  // 此时，workInProgressStackCursor.current 指向了 workInProgress
  // 这意味着，在接下来的渲染中，所有的 hooks 读取操作都会基于 workInProgress
  prepareFreshStack(current, workInProgress);

  // ... 渲染逻辑 ...

  // 3. 恢复栈状态
  stackCursor.current = prevStackCursor;
}

这个 prevStackCursor 是个什么鬼？它是为了处理递归的。

React 是递归渲染组件树的。当你渲染 App -> Parent -> Child 时，栈是不断增长的。
prepareFreshStack 在每一层递归调用时都会被触发（或者在顶层触发一次）。它确保了每一层组件都有自己独立的 Hooks 状态空间。

如果它不清理栈，那么当你在 Child 组件里修改了状态，这个修改可能会顺着栈“流”回 Parent，甚至 App，导致全局混乱。

第九部分：调试——如何发现状态不一致？

作为开发者，我们怎么知道 prepareFreshStack 没有正常工作呢？或者更准确地说，我们怎么知道我们的并发逻辑写对了？

通常，你会发现以下症状：

1. UI 卡死在 Loading 状态：数据明明加载了，但 Suspense 一直不消失。这是因为 prepareFreshStack 没有正确重置状态，导致组件认为还在加载中。
2. 状态跳变：你点击一个按钮，状态从 1 变成了 3，中间跳过了 2。这通常是因为在重试渲染时，旧的渲染残留影响了新的渲染。
3. 控制台报错：Maximum update depth exceeded。这通常是因为在渲染过程中修改了状态，导致无限循环。如果 prepareFreshStack 没有正确隔离每一层组件的状态，这种循环会非常容易发生。

你可以通过在 renderWithHooks 里打断点来观察 renderDidSuspend 的变化，或者观察 currentlyRenderingFiber 的变化，来验证 prepareFreshStack 的执行时机。

第十部分：总结——给大脑做个SPA

好了，咱们来总结一下 prepareFreshStack 的核心价值。

在 React 并发模式下，渲染不再是线性的、原子性的。它是一个充满了中断、挂起、重试的动态过程。

prepareFreshStack 就像是这个动态过程中的清洁工和重启按钮。

1. 清理垃圾：它擦除了上一次渲染遗留在栈里的无效数据。
2. 隔离上下文：它确保了当前正在渲染的组件树拥有独立的状态空间，不会受到父组件或其他组件的干扰。
3. 重置标志：它重置了挂起状态，告诉 React “我们可以重新开始了”。

没有它，React 就像是一个健忘的老头，一边炒菜一边切菜，最后把盘子扔进了垃圾桶。

通过理解 prepareFreshStack 以及它背后的栈光标机制，你才能真正驾驭 React 的并发模式。你不再是仅仅在写 JSX，你是在指挥一个精密的调度系统。

附赠：模拟代码

最后，为了让你彻底明白，我写了一个极度简化版的“伪 React”来模拟这个过程。你可以把它跑起来看看效果。

class MiniReact {
  constructor() {
    this.stack = [];
    this.renderDidSuspend = false;
  }

  // 模拟 prepareFreshStack
  prepareFreshStack() {
    console.log("🧹 准备新鲜栈：清理旧数据，重置状态...");
    this.stack = []; // 清空栈
    this.renderDidSuspend = false; // 重置挂起标志
  }

  // 模拟组件渲染
  renderComponent(name) {
    this.prepareFreshStack(); // 每次渲染前都清理

    console.log(`渲染组件: ${name}`);

    // 模拟状态
    let state = null;

    // 模拟 Hooks
    const useState = (initialValue) => {
      if (state === null) {
        state = initialValue;
        console.log(`  初始化状态: ${state}`);
      } else {
        console.log(`  读取状态: ${state}`);
      }
      return [state, (v) => { state = v; }];
    };

    // 执行组件逻辑
    const [count, setCount] = useState(0);

    if (count < 5) {
      console.log(`  状态未满，准备挂起...`);
      this.renderDidSuspend = true;
      throw new Error("SUSPENDED");
    }

    console.log(`  组件完成渲染: ${name}`);
    return `<${name}>`;
  }

  // 模拟调度循环
  scheduleWork() {
    try {
      const html = this.renderComponent("App");
      console.log("✅ 提交渲染结果:", html);
    } catch (e) {
      if (e.message === "SUSPENDED") {
        console.log("⚠️ 渲染挂起，准备重试...");
        setTimeout(() => {
          this.scheduleWork();
        }, 100);
      }
    }
  }
}

// 运行测试
console.log("--- 开始并发模拟 ---");
const app = new MiniReact();
app.scheduleWork();

当你运行这段代码时，你会看到 🧹 准备新鲜栈 被打印了多次。这就是 React 在幕后默默为你做的所有工作。

好了，今天的讲座就到这里。记住，每次你看到 React 优雅地处理了并发更新，都要感谢那个在幕后默默清理栈的 prepareFreshStack。

下课！去喝杯咖啡吧，你的代码现在更健壮了。