各位听众朋友，大家好！
欢迎来到今天这场名为《React 内部器官解剖学：批处理与 setState 的“猫鼠游戏”》的讲座。我是你们的主讲人，一个在 React 源码里摸爬滚打多年的资深“切图仔”。
今天，我们不谈业务逻辑，不谈 Hooks 的坑，我们要来点硬核的。我们要聊聊那个让无数 React 开发者又爱又恨、让 React 团队秃了又黑的机制——自动批处理。
尤其是，当你在点击按钮、输入框疯狂操作时，React 是如何像特工一样，在“进入 workLoop（工作循环）”之前，通过那些神秘的“标识位”，拦截住你的 setState 调用，把它们像沙丁鱼一样塞进同一个罐头里的。
准备好了吗？让我们把 React 的源码打开，像剥洋葱一样，一层一层，把那个叫“批处理”的洋葱皮给剥下来。
第一部分：如果不批处理，世界会怎样？
在讲原理之前，我们必须先理解为什么要搞批处理。这就像你点外卖，如果厨师（React）接到你的第一单，立马就把菜炒好端给你；接着接到第二单，又炒好端给你；接到第三单，再炒好端给你……
你会在 3 秒钟内吃掉 3 份饭，这叫什么？这叫消化不良，这叫 CPU 爆炸，这叫用户体验崩盘！
在 React 15 之前，如果你在事件处理程序里连续调用三次 setState，React 就会老老实实地执行三次渲染。每一次渲染，它都要去操作 DOM。对于浏览器来说，DOM 操作是昂贵的，就像是用金斧头砍柴。砍三下，DOM 就抖动三次。你的界面会像得了帕金森一样疯狂闪烁。
于是，React 团队决定搞个“打包员”。这个打包员的名字叫“批处理”。
它的任务很简单：把短时间内发生的多次状态更新，攒在一起，攒到一个合适的时机（也就是进入 workLoop 之前），一次性提交给渲染引擎。
第二部分：那个神秘的“守门员”——isBatchingUpdates
那么，这个打包员是怎么工作的呢？核心就在于一个标志位。在 React 16 的源码里，这个标志位叫 isBatchingUpdates。
你可以把它想象成一个门卫大爷。当你的代码执行时，如果门卫大爷手里拿着牌子写着“正在打包中”，那么任何试图进入渲染队列的 setState 都会被拦在门外，被塞进一个叫 pendingUpdateQueue 的篮子里。
如果门卫大爷手里拿着牌子写着“闲人免进”，那不好意思，你的 setState 必须立刻、马上、马上就执行渲染。
这个标志位是在哪里被设置的呢？是在事件处理程序开始的时候。
让我们来看看源码（React 16.13.4 版本 ReactUpdateQueue.js）：
// 这是一个全局变量（或者是线程局部存储，为了简单理解，我们当它是全局的）
let isBatchingUpdates = false;
// 这是一个非常核心的函数
export function enqueueUpdate(fiber, update) {
// 1. 首先检查门卫大爷的牌子
if (isBatchingUpdates) {
// 如果正在批处理，那就把更新扔进队列
// 注意：这里直接访问了 fiber 的队列
if (fiber.tag === ClassComponent) {
const classComponentFiber = fiber;
if (!classComponentFiber.updateQueue) {
classComponentFiber.updateQueue = new Queue();
}
classComponentFiber.updateQueue.enqueue(update);
} else {
if (!fiber.updateQueue) {
fiber.updateQueue = new Queue();
}
fiber.updateQueue.enqueue(update);
}
} else {
// 2. 如果没有批处理，那就直接调度渲染！
// 这就是为什么 setTimeout 里的 setState 会立即触发渲染
scheduleUpdateOnFiber(fiber, update, lane);
}
}看到了吗？这就是拦截的原理！enqueueUpdate 函数是 setState 的必经之路。它首先看一眼 isBatchingUpdates 这个标识位。
- 场景 A（批处理中）： 标志位为
true。函数直接返回，不做任何渲染调度，只把数据存在内存里。 - 场景 B（非批处理中）： 标志位为
false。函数直接调用scheduleUpdateOnFiber，这就像按下了一个炸弹的引信，React 马上就会开始干活。
第三部分：门卫大爷什么时候拿牌子？
关键来了：什么时候 isBatchingUpdates 会变成 true？
这就得提到 React 的“事件系统”了。
当你点击一个 <button> 或者在 <input> 里输入文字时，React 并没有直接把你的点击事件绑定到 DOM 上（那是 jQuery 的做法）。React 使用了事件委托。它会在 document 上监听所有的点击事件。
当事件发生时，React 会执行一系列复杂的逻辑，其中最重要的一步就是：
// 伪代码：React 事件处理入口
function dispatchEvent(event) {
// 1. 标记正在批处理
isBatchingUpdates = true;
try {
// 2. 执行你的代码
// 比如: setA(1); setB(2); setC(3);
// 这时候，你的三个 setState 都会被 enqueueUpdate 拦截，存进队列
event._reactName(event.target);
} finally {
// 3. 你的代码执行完了，把牌子放下
// 注意：这里还有一个微任务队列 flush
isBatchingUpdates = false;
flushBatchedUpdates();
}
}这是什么意思？
这意味着，在 onClick、onChange 等事件处理函数的执行期间，React 的“批处理模式”是开启的。
所以，如果你这样写：
function handleClick() {
setCount(count + 1); // 第1次更新：被拦截，存入队列
setCount(count + 1); // 第2次更新：被拦截，存入队列
setCount(count + 1); // 第3次更新：被拦截，存入队列
}React 会一口气把这三次更新都存起来，然后等你函数执行完，它才会统一去渲染。
但是！如果你把这段代码放到 setTimeout 里：
setTimeout(() => {
setCount(count + 1); // 此时，React 已经不在事件处理流程中，isBatchingUpdates = false
setCount(count + 1);
setCount(count + 1);
}, 0);在 setTimeout 回调执行的那一刻，React 的“批处理大门”已经关上了。所以，这三个 setState 会立刻触发三次渲染。
第四部分：进入 workLoop 之前——那个决定命运的瞬间
好了，我们已经把 setState 拦截到了队列里。现在，这些更新静静地躺在 pendingUpdateQueue 中。
下一步，就是进入 workLoop 了。这是 React 渲染的核心，它负责计算新的状态、生成虚拟 DOM、执行 Diff 算法、最后更新真实 DOM。
那么，workLoop 是如何知道要把这些更新取出来的呢？它又是如何保证在进入工作循环之前，这些更新已经被处理好了呢？
这里涉及到一个至关重要的函数：scheduleUpdateOnFiber。
当 enqueueUpdate 发现 isBatchingUpdates 为 false 时，它会调用 scheduleUpdateOnFiber。这个函数的任务就是触发渲染。
但在 React 18 引入并发模式之前，scheduleUpdateOnFiber 的逻辑非常直接。它会把更新分配到某个渲染 Lane（时间片）上，然后调用 requestWork，最终调用 renderRoot（也就是 workLoop）。
但是，对于那些在批处理中被拦截的更新，React 是怎么知道要把它们拿出来的呢？
其实，React 维护了一个全局的更新队列。当 isBatchingUpdates 为 true 时，所有的更新都被塞进了这个全局队列。当事件处理函数执行完毕，React 会调用一个名为 flushBatchedUpdates 的函数。
function flushBatchedUpdates() {
// 如果正在批处理，就不用刷
if (isBatchingUpdates) {
return;
}
// 遍历全局队列，取出所有待处理的更新
// 每取出一个，就调度一次渲染
while (workInProgressQueue.length > 0) {
const update = workInProgressQueue.shift();
scheduleUpdateOnFiber(update.fiber, update);
}
}注意这个 while 循环！
这就是 React 的“暴政”。它不管你调用了多少次 setState，也不管你传了什么值，它只管把你塞进来的东西全部拿出来。
- 拦截阶段：
onClick里的三个setState进来了，isBatchingUpdates是true，被塞进workInProgressQueue。 - 执行阶段： 你的
onClick函数执行完毕。 - 释放阶段：
flushBatchedUpdates被调用。它遍历队列，依次调用scheduleUpdateOnFiber。 - 渲染阶段：
workLoop开始运行，读取这三个更新，计算新的状态，更新界面。
结果： 你只看到了一次 UI 变化。React 的“打包员”成功完成了任务。
第五部分：React 18 的进化——isDiscreteEvent
但是，React 团队觉得 16 的批处理还不够完美。因为他们发现，有些更新必须非常快地显示出来，不能有任何延迟。
比如，你在输入框里打字。如果你打一个字，界面就卡顿一下，那用户体验就太差了。但是，React 16 的批处理机制是同步的，它必须把所有事件处理函数里的更新都攒完，再一次性渲染。
这导致了输入框的响应性变差。
于是，React 18 带来了并发模式，以及一个新的标识位：isDiscreteEvent（离散事件）。
什么是离散事件？
点击、键盘输入、鼠标移动等。这些是用户直接交互的动作，必须立即反馈。
什么是非离散事件？
setTimeout、requestAnimationFrame、Promise、IntersectionObserver。这些是异步操作，React 可以稍微等一下，把它们合并起来批处理。
React 18 修改了事件系统的逻辑：
function dispatchDiscreteEvent(eventType, listener, event) {
// 标记这是一个离散事件
isDiscreteEvent = true;
// ... 执行监听器 ...
isDiscreteEvent = false;
// 离散事件有自己的 flush 逻辑，确保立即渲染
flushDiscreteUpdates();
}在 React 18 中，当 isDiscreteEvent 为 true 时，React 会绕过常规的批处理队列，直接调用 flushDiscreteUpdates。
function flushDiscreteUpdates() {
// 如果正在批处理（比如在事件处理函数里），把更新存起来
if (isBatchingUpdates) {
// 存入 discreteUpdatesQueue
} else {
// 直接渲染！
// 这就是为什么 React 18 里，你在 onClick 里写 Promise 也能触发渲染
// 因为 Promise 回调被视为非离散事件（或者有特殊的批处理逻辑）
}
}这就解释了一个 React 18 的神奇现象：
在 React 18 之前，setTimeout 里的 setState 会被批处理吗？不会，因为它是异步的，它不会触发 React 的事件系统。
在 React 18 里，Promise 回调里的 setState 会批处理吗？会！ 因为 Promise 回调被视为非离散事件，React 会开启批处理模式。
React 18 通过引入 isDiscreteEvent 标识位，实现了更精细的控制。它把“必须马上显示”的更新和“可以合并显示”的更新分开了。
第六部分：实战代码演示——看穿它的伪装
为了让大家彻底明白，我们来写一段代码，模拟 React 16 和 React 18 的行为差异。
场景一：React 16 的传统批处理
function DemoComponent() {
const [count, setCount] = React.useState(0);
const [flag, setFlag] = React.useState(false);
// React 16 行为
const handleClick = () => {
setCount(count + 1); // 1. 被拦截
setCount(count + 1); // 2. 被拦截
setCount(count + 1); // 3. 被拦截
setFlag(!flag); // 4. 被拦截
console.log("状态已更新，但还没渲染");
};
return <button onClick={handleClick}>Click Me</button>;
}执行流程：
- 点击按钮。
handleClick执行。isBatchingUpdates变为true。setCount调用enqueueUpdate-> 发现isBatchingUpdates为true-> 把更新推入pendingUpdateQueue。setFlag同理，推入队列。handleClick执行完毕。flushBatchedUpdates执行。- 从队列里取出更新 ->
scheduleUpdateOnFiber->workLoop。 - 结果： 只渲染一次，count 变了，flag 也变了。
场景二：React 16 中的异步批处理（失效）
function DemoComponent() {
const [count, setCount] = React.useState(0);
const handleClick = () => {
setTimeout(() => {
setCount(count + 1); // React 16: 此时 isBatchingUpdates = false
setCount(count + 1); // React 16: 直接调度渲染
setCount(count + 1); // React 16: 直接调度渲染
}, 0);
};
return <button onClick={handleClick}>Click Me</button>;
}执行流程：
- 点击按钮。
handleClick执行完毕，isBatchingUpdates变为false。setTimeout被推入宏任务队列。- 浏览器执行宏任务。
- 进入
setTimeout回调。 setCount调用enqueueUpdate-> 发现isBatchingUpdates为false-> 直接调用scheduleUpdateOnFiber。- React 开始第一次渲染。
setCount再次调用 -> 直接调用scheduleUpdateOnFiber。- React 开始第二次渲染。
setCount第三次调用 -> 直接调用scheduleUpdateOnFiber。- React 开始第三次渲染。
结果： 你点击一次，界面会闪烁三次。这就是 React 16 的“痛点”。
场景三：React 18 的并发批处理
function DemoComponent() {
const [count, setCount] = React.useState(0);
const handleClick = async () => {
await new Promise(resolve => setTimeout(resolve, 0));
setCount(count + 1); // React 18: 这是一个非离散事件，会自动批处理
setCount(count + 1);
setCount(count + 1);
};
return <button onClick={handleClick}>Click Me</button>;
}执行流程：
- 点击按钮。
handleClick是 async 函数。- React 把这个函数的执行视为“非离散事件”。
isBatchingUpdates被设置为true。await执行，setTimeout被推入微任务队列。- 微任务执行完毕，
handleClick恢复执行。 - 三个
setCount被调用。 enqueueUpdate发现isBatchingUpdates为true-> 被拦截。handleClick执行完毕。flushBatchedUpdates执行。- 结果： 只渲染一次。
第七部分：flushSync —— 强制打破规则的“核武器”
既然 React 这么喜欢批处理，那有没有办法强制它不批处理呢？
有的。React 18 提供了一个神器：ReactDOM.flushSync。
它的原理很简单：在调用 flushSync 包裹的代码块时，React 会临时关闭批处理机制，强制执行渲染。
import { flushSync } from 'react-dom';
function DemoComponent() {
const [count, setCount] = React.useState(0);
const handleClick = () => {
// 强制同步更新，不批处理
flushSync(() => {
setCount(count + 1); // 立即渲染
});
// 此时，React 已经渲染完了
console.log(count); // 你能看到最新的 count
// 后面的 setState 会正常批处理
setCount(count + 1); // 这会被批处理
setCount(count + 1);
};
return <button onClick={handleClick}>Click Me</button>;
}源码逻辑（伪代码）：
function flushSync(fn) {
// 1. 临时标记：强制批处理关闭
const prevIsBatchingUpdates = isBatchingUpdates;
isBatchingUpdates = false;
try {
// 2. 执行你的函数
fn();
} finally {
// 3. 恢复之前的标记
isBatchingUpdates = prevIsBatchingUpdates;
// 4. 强制刷新所有待处理的更新
flushBatchedUpdates();
}
}flushSync 就像是给 React 的批处理大门上了一把锁，然后强行把门踹开，把里面的东西倒出来。
第八部分：总结——标志位背后的智慧
好了，我们终于讲到了最后。
React 的自动批处理，本质上是一场“以空间换时间”的博弈。
- 标识位：
isBatchingUpdates和isDiscreteEvent，就是这场博弈的裁判。 - 拦截：在
enqueueUpdate函数中，通过检查这些标识位，决定是把更新存进队列（牺牲即时性，换取性能），还是直接触发渲染（牺牲性能，换取响应性）。 - 进入 workLoop：这是渲染的终点。React 确保在进入这个终点之前，所有的更新都已经被整理好了，避免在
workLoop里反复切换上下文。
React 之所以这么做，是因为它知道：DOM 更新是昂贵的，而内存操作是廉价的。
把多次内存操作合并成一次 DOM 操作，这就是 React 优化性能的精髓所在。
下次当你写代码时，如果你发现你在 setTimeout 里调用 setState 导致了多次渲染，不要惊讶，那是 React 的“打包员”下班了，它没来得及把你的包裹发出去。
如果你发现你在 onClick 里调用 setState 没有触发多次渲染，那是因为那个“守门大爷”正在尽职尽责地守着大门呢！
希望今天的讲座能让你对 React 的批处理机制有一个更深的理解。记住，优秀的工程师不仅要会用 API，更要懂得 API 背后的逻辑。这不仅能帮你写出更快的代码，还能在面试的时候，让面试官为你鼓掌！
好了，今天的解剖课就到这里。大家如果还有什么关于 workLoop 或者 Fiber 的问题，欢迎在课后提问。下课！
（注：以上代码和逻辑基于 React 16 和 React 18 的部分源码实现原理分析，具体实现细节可能因版本迭代而有所不同。）