React 自动批处理（Automatic Batching）的实现原理：探究渲染进入 workLoop 前如何通过标识位拦截并合并多次状态更新

大家好，我是你们的老朋友，那个在源码的泥潭里摸爬滚打、专门跟 React 源码过不去的资深编程专家。

今天，我们要聊一个 React 里特别“性感”的话题：自动批处理。这玩意儿听着高大上，其实原理就像咱们在超市结账——如果你买十个东西，店员非得一个一个收，你肯定得骂街；但如果店员说“好嘞，把东西都放篮子里，算你一起”，这体验就瞬间提升了十倍。

在 React 里，这也叫“状态更新合并”。今天，我就不整那些虚头巴脑的术语，咱们直接把 React 的裤衩子扒下来，看看它是怎么在 workLoop 进场前，通过那一串串标志位，把你那原本想“杀马特”般狂暴渲染的代码，硬生生给“批处理”成优雅的“艺术品”的。

准备好了吗？戴上安全帽，我们要开钻了。

第一部分：重新渲染的“连环杀”

在讲原理之前，咱们得先吐槽一下，如果不批处理，React 会是个什么样？

假设你有个按钮，你手速很快，或者脑子一热，连着点了好几下：

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

  const handleClick = () => {
    setCount(c => c + 1);
    setCount(c => c + 1);
    setCount(c => c + 1);
  };

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

如果是 React 17 或者更早的版本，你会得到什么？你会得到一个连环杀。也就是：三次渲染。

第一个 setCount 执行，触发渲染，count 变成 1。
第二个 setCount 执行，触发渲染，count 变成 2。
第三个 setCount 执行，触发渲染，count 变成 3。

这三个渲染是连贯的，DOM 操作是频繁的，性能开销是巨大的。这就是所谓的“状态更新抖动”。

那么，React 为了保命，引入了批处理。

第二部分：React 17 的“硬核守门员”

在 React 18 之前，批处理还是个“打工人”，是有条件限制的。它只在你调用 onClick 这种 React 事件处理器的时候，才会打开大门。

这就有意思了。React 做了一个全局的守门员，名字叫 isBatchingUpdates。这就像是一个公司的保安，只有当你是“内部员工”（React 事件）的时候，保安才会放行。

源码级回顾（简化版）：

当你在 React 17 中点击一个按钮，React 的内部流程是这样的：

捕获事件：浏览器告诉你，有个点击事件发生了。
调用调度器：React 拦截这个事件，开始调用 React 的调度逻辑。
开启“批处理”模式：React 在执行你的 onClick 代码之前，会干一件大事——把全局标志位 isBatchingUpdates 设为 true。
执行你的代码：你的 handleClick 开始跑，里面调了三次 setState。
执行结束：你的 handleClick 跑完了，React 把 isBatchingUpdates 设回 false。
进入 workLoop：此时，你的三次更新早就被扔进了一个“更新队列”里。因为 isBatchingUpdates 是 true，React 拒绝立即渲染。它把这三个更新包在一起，打包成一个任务，扔给了调度器（Scheduler）。
渲染：调度器告诉你“好了，我有空了”，React 才真正开始执行渲染逻辑，把 count 变成 3。

这就是经典的“React 17 模式”。

第三部分：React 18 的“自动化革命”

但是，React 18 并不满足。它想：“我为什么要让你点按钮我才知道要批处理？我能不能在所有地方都批处理？”

于是，React 18 引入了自动批处理。

这时候，那个简单的 isBatchingUpdates 全局布尔值已经不够用了。为了配合并发特性，React 18 引入了调度器，并且引入了一套基于优先级的机制。

在 React 18 里，React 不再是简单的“是/否”守门员，它变成了一个看时间表的管理员。

3.1 优先级的入场券

在 React 18 中，所有的任务都有优先级。React 定义了几种优先级：

DiscreteEventPriority (离散事件优先级)：比如点击、输入、鼠标移动。这是高优先级。
ContinuousEventPriority (连续事件优先级)：比如动画帧回调。
IdlePriority (空闲优先级)：后台任务。
LowPriority (低优先级)：比如非关键的数据拉取。

核心实现逻辑：

当你在浏览器中点击一个按钮时，React 会这么干：

// 这是一个高度简化的伪代码，模拟 React 18 的调度行为

function dispatchDiscreteEvent(eventType, listener, event) {
  // 1. React 拿到这个事件，判断它是“离散事件”（比如点击），给它贴上“高优先级”标签
  const priority = DiscreteEventPriority;

  // 2. 调用调度器的 runWithPriority，在这个高优先级上下文中执行你的回调
  // 这就像是你把你的 handleOnClick 代码送进了“VIP 通道”
  Scheduler_runWithPriority(priority, () => {
    // 3. 执行用户代码
    listener(event);
  });
}

// 你的代码在 VIP 通道里跑
function handleClick() {
  setCount(c => c + 1);
  setCount(c => c + 1);
  setCount(c => c + 1);
}

重点来了： 在这个 runWithPriority 的回调里，React 内部有一个标志位 isBatchingUpdates（或者叫 ReactCurrentBatchConfig.current），被设为 true。

3.2 Promise 和 setTimeout 呢？

既然自动批处理这么好，那为什么 Promise 和 setTimeout 里的 setState 不会自动批处理呢？

因为 Promise 和 setTimeout 在 React 眼里，属于异步任务，它们属于不同的优先级队列。

当你用 setTimeout 时，你告诉浏览器：“哥们，别管了，我一会再处理。”
React 的调度器这时候会说：“行，既然是异步的，那我就把这个任务往后放。但是，既然你是个单独的异步任务，我就不给你批处理了。你在这个 setTimeout 里面调了 10 次 setState？好嘞，那我给你触发 10 次渲染。别怪我没提醒你。”

这就是为什么 React 18 还需要 flushSync 来强制批处理的原因。

第四部分：深度剖析——如何拦截并合并

好，现在到了最核心的部分。我们要看看在 workLoop 进场之前，React 到底是怎么“拦截”并“合并”这些更新的。

4.1 更新队列的“坑”

React 内部维护了一个更新队列，通常叫 updateQueue。当你调用 setState 时，React 并不是直接改 DOM，而是往这个队列里扔一个对象：

// React 内部的一个 Update 结构
const update = {
  lane: lane, // 优先级车道
  action: action, // 更新函数
  next: null, // 指向下一个 Update
};

当 isBatchingUpdates 为 true 时，React 的逻辑是这样的：

function enqueueUpdate(fiber, update) {
  // 如果正在批处理中...
  if (isBatchingUpdates) {
    // 1. 拦截！绝不立即渲染！
    // 2. 把 update 放进 current fiber 节点的更新队列里
    addUpdateToQueue(fiber, update);
  } else {
    // 如果不在批处理中（比如 Promise 回调里），
    // 那就给你直接触发一个渲染请求！
    // 比如说：立即扔给 Scheduler，让它赶紧跑 workLoop。
    scheduleUpdateOnFiber(fiber, update);
  }
}

这就是拦截。它通过控制 isBatchingUpdates 这个全局开关，决定了更新是进“缓冲区”（队列），还是直接上“流水线”。

4.2 workLoop 前的合并大法

当所有事件回调执行完毕，React 的调度器开始工作。它会检查：“刚才那帮用户到底干了啥？”

它发现你点了三次按钮，于是它从队列里拿出了三个 Update 对象。

合并逻辑：

React 拿着这三个 Update，开始执行合并。

假设初始状态是 { count: 0 }。

第一个 Update：count => count + 1。合并后状态变成 { count: 1 }。
第二个 Update：count => count + 1。合并后状态变成 { count: 2 }。
第三个 Update：count => count + 1。合并后状态变成 { count: 3 }。

最终，React 生成一个全新的状态对象 { count: 3 }，把这个新状态传给 workLoop。

在 workLoop 里，React 会拿这个新状态去比对旧状态：

旧：{ count: 0 }
新：{ count: 3 }
差异：count 从 0 变到了 3。

然后，React 就只做一次 DOM 更新：div.textContent = 3。

怎么样？是不是很优雅？

第五部分：代码实战——手动触发 flushSync

为了演示 flushSync 是如何打破自动批处理的，我们来写个代码。

场景：你想在点击按钮的时候，不仅更新状态，还想在点击的一瞬间立刻强制更新 UI，不让批处理等你。

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

  const handleClick = () => {
    // 普通更新：会被自动批处理，只有最后一次生效
    setCount(c => c + 1);
    setCount(c => c + 1);

    // 强制更新：必须立即执行
    // flushSync 会强制把 React 丢进 ImmediatePriority 队列
    // 这意味着它会打断当前的批处理流程，立刻开始渲染
    React.flushSync(() => {
      setCount(c => c + 1);
    });
  };

  return <button onClick={handleClick}>Count is {count}</button>;
}

执行流程分析：

用户点击。
handleClick 执行。
前两个 setCount 被正常批处理，扔进队列，状态没变，没渲染。
遇到 flushSync。
React 调用 Scheduler_runWithPriority(ImmediatePriority, ...)。
立即触发渲染。此时状态变成了 1。
flushSync 结束。
后面的 setCount 继续在批处理队列里排队。
整个事件循环结束后，批处理队列里的更新生效，状态变成了 2（因为初始0 + flushSync里的1 + 最后一个1）。

看，flushSync 就像是在安静的晚宴上突然扔了一个盘子，强制所有人停下来看它。

第六部分：源码里的那些“坑”与“彩蛋”

在深入源码的过程中，你会发现 React 为了实现自动批处理，做了很多“补丁”。

6.1 ReactCurrentBatchConfig

在 React 源码里，有一个全局对象叫 ReactCurrentBatchConfig。

// 简化版源码逻辑
const ReactCurrentBatchConfig = {
  current: null, // 默认是 'batched' 或者是优先级对象
};

当 React 调度一个事件时：

function scheduleEvent(eventType, event) {
  const priority = DiscreteEventPriority; // 获取优先级

  // 这里就是核心！
  // 我们把这个优先级对象赋值给 current
  const prevConfig = ReactCurrentBatchConfig.current;
  ReactCurrentBatchConfig.current = priority;

  try {
    // 执行用户回调
    userCallback(event);
  } finally {
    // 回调结束，恢复默认配置
    ReactCurrentBatchConfig.current = prevConfig;
  }
}

所有的 enqueueUpdate 函数在执行时，都会检查这个 ReactCurrentBatchConfig.current。

如果它是 batched（批处理模式），那就进队列。
如果它是 discrete（离散模式，比如手动 flushSync），那就直接触发渲染。

6.2 终极合并：batchesPendingUpdates

还有一个概念叫 batchesPendingUpdates。在 React 的 Fiber 架构中，每个 Fiber 节点（代表一个组件）都有自己的更新队列。

当 isBatchingUpdates 为 true 时，React 不会把更新直接挂在当前 fiber 上，而是挂在父级或者某个临时的“批处理 fiber”上。

这就像是你想寄信，如果邮局在营业（批处理开启），你把信交给前台，前台攒够了再寄。如果邮局关门了（批处理关闭），你得直接去找邮递员。

第七部分：总结与实战建议

好了，讲了这么多原理，咱们来点实用的。作为一个资深专家，我教你几招如何利用这个机制优化你的代码。

1. 别害怕 useState 的连续调用
以前我们要用 useEffect 来做 setState 的合并，或者用 useReducer。现在有了自动批处理，你可以放心地在事件处理函数里连点三下 setState，React 会帮你合并。这不仅是性能优化，更是代码简洁性的胜利。

2. 警惕异步副作用
如果你在 useEffect 里调用了 setTimeout，并且在这个 setTimeout 里修改了状态，React 18 默认是不会批处理的。

useEffect(() => {
  setTimeout(() => {
    setCount(count + 1); // 这里会触发一次额外的渲染
  }, 1000);
}, []);

如果你发现你的 useEffect 导致了多余的渲染，检查一下是不是在异步回调里调用了 setState。

3. flushSync 是一把双刃剑
虽然它强制渲染看起来很爽，但它会打断批处理。如果你在一个批处理的上下文中频繁调用 flushSync，可能会导致你失去了批处理带来的性能优势。只有当你需要在用户交互后立即同步看到 UI 变化（比如做数据校验，错误提示），才用它。

最后的彩蛋：聊聊 “Automatic Batching” 的未来

React 的野心很大。目前，自动批处理已经支持了：

原生事件处理器。
事件回调。
setTimeout (从技术上讲，React 18 支持 setTimeout 里的批处理，但这取决于浏览器的事件循环特性，比较复杂，通常建议还是用 flushSync 或者事件处理)。
甚至支持了 AbortController！ 当 abort 事件触发时，React 也会把回调里的状态更新进行批处理。

你可以看到，React 正在试图把“批处理”变成一个默认行为，而不是一个需要你手动的“技巧”。

专家寄语：

看懂了自动批处理，你就看懂了 React 并发模式的基石。它不仅仅是一个优化手段，更是一种设计哲学：在用户感知不到的地方，默默地把重复的事情做成一次。

下次当你看到控制台里那条干干净净的“Rendered X times”日志时，别忘了那个在后台默默合并队列、拦截更新的“守门员”机制。

好了，今天的源码剖析就到这里。如果你觉得这篇文章让你对 React 的批处理有了新的认识，别忘了点赞收藏。毕竟，技术这东西，看懂了是财富，看不懂是玄学。咱们下期再见！