React 并发渲染中断与恢复的执行上下文

各位好，我是你们的 React 架构师。今天我们不聊怎么写业务，不聊怎么用 Ant Design，我们来聊聊 React 的“心脏”是怎么跳动的。

如果你以前用过 React，你一定有过这种体验：当你点击一个按钮，页面就像被冻住了一样，那个加载圈转得比你的耐心还慢，直到渲染完成，页面才“嘭”地一下全部弹出来。这种体验，我们称之为“UI 冻结”，也就是俗称的“卡顿”。

为了解决这个问题，React 18 引入了并发渲染。这玩意儿听起来很高大上，其实原理并不复杂，它就像是把原本“一口气跑完马拉松”变成了“跑跑停停，看路况调整速度”。

今天，我们就来扒开 React 的裤裆——哦不，是代码底裤，看看在这个并发模式下，当渲染被“中断”又“恢复”的时候，那个神秘的“执行上下文”到底发生了什么。

一、 同步渲染的“便秘”体验

在并发模式之前，React 的渲染是同步的。想象一下，你在写代码，你的电脑 CPU 是你的大脑，浏览器是你的手。

在同步模式下，React 说：“我要渲染这个组件树，从根节点开始，一级一级往下走，每一个节点都要算出来，渲染出来，完了再走下一个。如果算到一半浏览器说‘你卡顿了’，React 会直接被浏览器挂起，直到你算完。这就像你便秘一样，憋着，憋到最后一刻才释放，这期间你什么也干不了。”

这种同步模式有个致命问题：阻塞。如果页面树很深，或者某个组件里有个死循环，整个页面就瘫痪了。

二、 Fiber 树：React 的身体结构

为了解决这个问题，React 重写了底层架构，引入了 Fiber。你可以把 Fiber 理解为 React 的身体结构。每个组件实例都是一个 Fiber 节点。

一个 Fiber 节点长什么样？它就像一个结构体（在 JS 里是个对象），里面装了当前组件的状态、DOM 引用、子节点引用、兄弟节点引用，还有一个最重要的属性：type（它是干嘛的）。

更重要的是，Fiber 节点有状态机：

1. WorkInProgress: 正在构建的树。React 在渲染新状态时，会先在内存里构建这棵树。
2. Current: 已经渲染在屏幕上的树。

并发渲染的核心就是：React 并不是一次性把整棵 WorkInProgress 树算完，而是像切蛋糕一样，切一块，算一块，渲染一块，然后停下来，看一眼调度器。

三、 时间切片：切蛋糕的艺术

浏览器有一个限制，主线程每帧（通常 16ms）只能干 50ms 的事（为了留出 16ms 给重绘和合成）。如果超过 50ms，页面就会掉帧。

React 的调度器（Scheduler）就是那个切蛋糕的刀。它把渲染任务切成无数个小块，每块只跑 5ms。

// 这是一个伪代码，为了让你理解 Scheduler 的意图
function renderChunk() {
  // 1. 从 Fiber 树里取下一个节点
  const nextNode = workInProgressRoot.next;

  // 2. 处理这个节点
  reconcileNode(nextNode);

  // 3. 把这个节点挂载到 DOM
  commitNodeToDOM(nextNode);

  // 4. 检查是否还有任务
  if (hasMoreWork) {
    // 5. 告诉调度器：“我干完了，如果你有空，下次再叫我，别让我等太久”
    requestIdleCallback(renderChunk, { timeout: 50 });
  } else {
    // 6. 没活儿了，更新 Current 指针，页面刷新完成
    currentRoot = workInProgressRoot;
    workInProgressRoot = null;
  }
}

看懂了吗？这就是“时间切片”。渲染是断续的。

四、 中断：电话响了怎么办？

现在，假设 React 正在渲染第 100 层的组件，它正在算第 100 层的 props，算到一半，用户突然点击了一个“取消”按钮。

这时候发生了什么？这就是中断。

React 的调度器收到了一个高优先级的更新（比如用户的点击事件）。调度器会立刻打断当前的渲染任务。

关键问题来了：中断的时候，那个“正在渲染的上下文”去哪了？它丢了吗？

答案是：它被保存下来了，但它是“挂起”的。

五、 执行上下文的保存与恢复

这是今天讲座的核心。当 React 中断时，它并没有把脑子扔掉。它保存了以下关键信息：

1. 当前正在处理的 Fiber 节点：比如它停在了第 100 层组件的 workInProgress 节点上。
2. 已经构建好的子树：比如第 1 层到第 99 层的 DOM 已经更新完毕，甚至已经提交到屏幕上了。
3. 剩余的更新队列：原本计划在第 101 层、第 102 层要做的更新，还在队列里等着呢。

1. 上下文的隔离

React 在渲染过程中维护了一个全局变量，通常叫 workInProgress（工作指针）。

当高优先级任务插入时，React 会暂停当前的 workInProgress 构建。此时，屏幕上的 DOM 还是旧的（Current 树），新的 DOM 还在内存里没画出来。

2. 上下文的切换

这时候，React 会开始构建一个新的、更高优先级的渲染树。这个过程会覆盖全局的 workInProgress 指针。

这就是“执行上下文”的切换。

• 旧上下文（低优先级）：被挂起，存放在内存里，等待恢复。
• 新上下文（高优先级）：被激活，开始计算。

举个例子：

用户正在输入搜索词，React 正在渲染搜索建议列表（低优先级）。
用户突然点击了“保存”按钮（高优先级）。

此时：

• 旧上下文：正在计算搜索建议列表的第 50 个建议。
• 新上下文：正在计算“保存”按钮的点击状态。

React 会丢弃旧上下文的计算结果（因为搜索建议列表反正也要被新输入覆盖了），直接开始渲染新上下文。

六、 恢复：跑完马拉松

过了一会儿，高优先级任务（保存按钮）渲染完成了。这时候，调度器一看，没活儿了，或者低优先级任务又该干活了。

React 开始恢复。

它会检查之前挂起的上下文：

1. 如果那个上下文还有价值（比如虽然高优先级任务完成了，但低优先级任务还没做完，或者高优先级任务又触发了新的低优先级任务），它就会继续。
2. 如果那个上下文已经完全没用了（比如高优先级任务覆盖了旧任务的所有内容），那就直接丢弃，不用恢复了。

恢复的本质就是：从之前挂起的那个 Fiber 节点继续往下走。

// 恢复时的伪代码逻辑
function resumeRendering() {
  // 1. 检查之前挂起的节点是否已经完成了
  if (workInProgressNode.isCompleted) {
    // 如果完成了，提交这棵树到屏幕
    commitRoot();
  } else {
    // 如果没完成，继续干！
    // 从上次停下的地方继续
    reconcileNode(workInProgressNode);
    requestIdleCallback(resumeRendering);
  }
}

七、 Effect 的语义变化：最大的坑

并发渲染最让人头秃的地方在于 useEffect。

在同步模式下，useEffect 是在渲染完成后、提交 DOM 之前运行的。
在并发模式下，useEffect 是在渲染恢复之后运行的。

为什么？

因为如果在渲染过程中（即“中断”的时候）运行 Effect，那意味着你要去操作 DOM，这会破坏 React 的调度。而且，如果渲染被中断了，Effect 运行的环境（上下文）可能已经变了。

场景模拟：

function Counter() {
  const [count, setCount] = useState(0);

  // 这是一个同步副作用，会立即执行
  console.log('useEffect 触发'); 

  useEffect(() => {
    console.log('Effect 执行了', count);
    document.title = `Count: ${count}`;
  }, [count]);

  return <button onClick={() => setCount(c => c + 1)}>Click</button>;
}

在并发模式下，当你疯狂点击按钮时：

1. React 开始渲染 count=1。
2. 渲染到一半，被中断（因为浏览器空闲了，或者有新任务）。
3. Effect 不会在此时执行（虽然 console.log 可能会打印，因为 effect 闭包捕获了变量，但 DOM 操作被挂起）。
4. React 继续渲染 count=2。
5. Effect 也不会在此时执行。
6. 最后，渲染完成，Effect 才会一次性执行，此时 count 可能已经是 5 了。

注意： 只有在同一个渲染阶段内，Effect 不会运行。只有在渲染阶段完全结束后，Effect 才会运行。这保证了 Effect 运行时，React 处于稳定状态。

八、 实战演练：用 useTransition 掌控上下文

为了演示中断与恢复的上下文切换，我们需要用到 startTransition。

startTransition 允许我们将一个更新标记为“低优先级”，从而让高优先级的更新（比如输入框的内容）能够中断低优先级的更新（比如搜索建议列表）。

import { useState, useTransition } from 'react';

function SearchPage() {
  const [input, setInput] = useState('');
  const [list, setList] = useState([]);
  const [isPending, startTransition] = useTransition();

  // 高优先级更新：直接更新输入框
  // 这个更新不会被中断，因为它是用户直接输入的
  const handleInputChange = (e) => {
    const value = e.target.value;
    setInput(value); 
  };

  // 低优先级更新：通过 startTransition 包裹
  // 这个更新会被中断！
  const handleSearch = (query) => {
    startTransition(() => {
      // 这里是低优先级上下文
      // 如果此时用户疯狂输入，这个回调里的逻辑会被频繁打断
      const results = fetchResults(query);
      setList(results);
    });
  };

  return (
    <div>
      <input onChange={handleInputChange} placeholder="Type here..." />
      {/* 如果列表正在加载（pending），显示加载中 */}
      {isPending && <div>Loading suggestions...</div>}
      <ul>
        {list.map(item => <li key={item.id}>{item.name}</li>)}
      </ul>
    </div>
  );
}

在这个代码里发生了什么？

1. 用户输入 “A”。
2. handleInputChange 执行，setInput('A')。这是一个高优先级更新。React 立即构建新的上下文，渲染输入框为 ‘A’。此时，低优先级的上下文（搜索建议列表）被挂起。
3. 用户继续输入 “B”。
4. handleInputChange 再次执行，setInput('B')。React 再次中断低优先级上下文，渲染输入框为 ‘B’。
5. 此时，输入框已经变成了 ‘B’。之前 ‘A’ 的上下文已经被覆盖了。
6. 当用户停下输入，React 恢复低优先级上下文，开始计算 ‘B’ 的搜索建议。

这就是并发渲染的核心：通过优先级控制上下文的切换。

九、 执行上下文的隔离与清理

你可能要问了：如果我在渲染过程中（低优先级上下文）调用了一个 setState，这个新的更新会怎么处理？

这涉及到 React 的更新队列。

在低优先级上下文中，如果你调用了 setState，这个更新会被放入队列中。
当低优先级上下文恢复时，React 会检查队列：

1. 如果队列里只有低优先级更新，那就一起执行。
2. 如果队列里混入了高优先级更新（比如用户又点击了按钮），那么低优先级上下文会被丢弃，直接开始高优先级上下文。

这就像你在写论文（低优先级），写着写着觉得口渴了（高优先级），你放下笔去喝水。等你喝完水回来，发现刚才写的部分可能已经过时了，或者你决定重新写。

十、 flushSync：强制同步的暴力美学

有时候，我们不想让上下文被中断，或者我们想确保某个更新必须在下一个渲染前完成，我们可以使用 flushSync。

import { flushSync } from 'react-dom';

function App() {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    // 强制同步更新，阻塞渲染线程
    flushSync(() => {
      setCount(count + 1);
    });

    // 这里的 console.log 保证能看到 count 的最新值
    console.log(count); 
  };

  return <button onClick={handleClick}>Click</button>;
}

flushSync 的作用是：它把 setState 包裹起来，强制 React 在这个函数执行完之前，不进行任何其他渲染（不进行任何上下文切换），直接算完，提交，再返回。

这会破坏并发性能，但能保证逻辑的绝对顺序性。在并发模式下，如果你在 useEffect 里依赖某些状态，而这些状态是通过 flushSync 强制更新的，你可能会遇到一些奇怪的时序问题，所以慎用。

十一、 调度器的博弈

React 的调度器（基于 Scheduler 库）是执行上下文管理的幕后黑手。

调度器会根据以下因素决定是“中断”还是“恢复”：

1. 优先级：高优先级任务永远插队。
2. 任务类型：动画帧任务（requestAnimationFrame）通常比空闲回调（requestIdleCallback）优先级高。
3. 输入延迟：如果用户输入很慢，说明用户在思考，调度器可能会给渲染更多时间。

举个有趣的例子：

React 就像一个尽职的保姆带两个熊孩子。

• 孩子 A（高优先级）：饿了，要吃饭。
• 孩子 B（低优先级）：在搭积木。

正常渲染：先喂 A，再搭积木。
并发渲染：

1. 喂 A，正喂到一半，B 突然哭闹了（用户操作）。
2. 保姆立刻扔下勺子，去哄 B。
3. B 哄好了，保姆回头一看，A 的饭还没喂完。保姆决定：放弃 A 的这勺饭，直接给 A 倒进嘴里，然后继续喂 A。
4. 喂完 A，保姆才回来继续搭积木（恢复低优先级上下文）。

在这个过程中，A 的“进食上下文”被中断了，但被重新激活了；B 的“积木上下文”被中断了，然后被恢复了。

十二、 嵌套组件的上下文传递

当一个组件树很深时，中断和恢复发生在哪里？

假设我们有 100 层组件：
App -> Page -> Content -> Sidebar -> Search -> Suggestions -> List -> Item

如果中断发生在 Item 层级：

1. React 会从 Item 往回回溯。
2. 检查 List 是否完成？没完成，继续渲染 List。
3. 检查 Suggestions 是否完成？没完成，继续渲染 Suggestions。
4. …

React 不会只中断叶子节点，它会中断整个子树。

上下文的传递是连续的。 只要父节点没渲染完，子节点就不可能渲染完。

function Parent() {
  console.log('Parent render start');
  const [state, setState] = useState(0);

  return (
    <div>
      <ChildA />
      <ChildB state={state} />
    </div>
  );
}

function ChildA() {
  console.log('ChildA render start');
  return <div>Child A</div>;
}

function ChildB({ state }) {
  console.log('ChildB render start');
  // 如果 ChildB 里有个很耗时的计算
  const expensiveValue = useMemo(() => computeExpensive(state), [state]);

  return <div>Child B: {expensiveValue}</div>;
}

如果在渲染 ChildB 的过程中中断，ChildA 可能早就完成了。但 ChildB 本身就是中断点。当恢复时，ChildB 会从它断掉的地方继续。

十三、 调试并发渲染

React 18 提供了一个调试工具 experimental_isSomeBatchingActive()。虽然这个 API 名字有点拗口，但它能帮你判断当前代码是否在 React 的某个批处理上下文中。

function Component() {
  console.log('Is batching?', experimental_isSomeBatchingActive());

  // 如果返回 true，说明你在 React 的某个上下文中（比如事件处理、startTransition）
  // 如果返回 false，说明你在 React 之外（比如 setTimeout，或者直接调用 setState）
}

这能帮你理解为什么某些副作用没有按预期触发。

十四、 总结一下执行上下文的流转

让我们把刚才说的串起来，画一个脑图：

1. 初始化：workInProgress 指向根节点。开始渲染。
2. 执行：深度优先遍历。渲染一个节点，更新 DOM。
3. 中断：调度器检测到更高优先级任务，或者超时。
   • 状态：workInProgress 指针暂停在当前节点。
   • DOM：当前节点及其子树已提交（或者部分提交）。
   • 上下文：挂起。
4. 切换：React 创建新的 workInProgress 树（高优先级）。
5. 恢复：高优先级任务完成。
   • 检查：低优先级任务是否还有价值？
   • 继续：如果是，将 workInProgress 指针移回低优先级节点，继续渲染。
   • 丢弃：如果低优先级任务被新任务完全覆盖，则丢弃旧上下文。

十五、 性能优化的终极指南

理解了上下文的中断与恢复，你就能写出更好的代码：

1. 把耗时的计算放在 startTransition 里：如果你在渲染列表，不要在渲染列表的同时做复杂的数据处理。把数据处理放到 startTransition 里，这样当用户快速输入时，列表渲染会被中断，输入框响应会非常快。
2. 避免在渲染路径中使用昂贵的计算：如果计算是同步的，它会阻塞整个上下文。如果必须计算，尽量用 useMemo 或 useCallback 缓存，或者放在 startTransition 里。
3. 理解 Effect 的时机：不要在 Effect 里依赖异步状态。Effect 只在渲染阶段完全结束后运行一次。如果你在 Effect 里发请求，请求回来的数据更新了 State，React 会再次触发渲染，但这已经是下一轮渲染了，不是 Effect 内部。

十六、 最后的思考

并发渲染不仅仅是一个技术特性，它是一种思维模式的转变。它要求我们接受“不完整”和“不连续”。

就像生活一样，你不可能一口气做完所有事。有时候你需要停下来，去处理突发状况（中断），有时候你需要回过头来补上之前没做完的事（恢复）。

React 的执行上下文管理，就是那个帮你记住“你刚才做到哪了”的笔记本。它保证你不会因为一次电话响（高优先级任务），就把脑子（渲染上下文）彻底忘光。

希望今天的讲座能让你对 React 的并发渲染有个更直观、更幽默的理解。下次当你看到页面流畅地切换，或者在输入框疯狂打字时，你能心里默默念叨一句：“看，那个调度器，正在切蛋糕呢。”

好了，今天的讲座到此结束。代码写起来吧！