大家好，我是你们的老朋友，一个在 React 代码堆里摸爬滚打多年，头发比头发丝还少的资深编程专家。
今天，我们要聊的话题非常硬核，也非常“润物细无声”。咱们不聊组件怎么写，不聊 Hooks 怎么用，咱们聊聊 React 最核心的“性格”——批处理（Batching）。
你们有没有过这种经历：你在写代码的时候，为了测试状态更新，在控制台疯狂地调用 setState，心里想着：“React 你个坏孩子，你肯定得给我渲染个一百次吧？”结果呢？React 轻轻地吐出一个数字：“一次就好，剩下的你自己猜。”
这就是批处理。它是 React 为了保命而发明的魔法。
今天这堂课，我们就来扒一扒 React 批处理是怎么进化的。从早期的“手动挡”时代，到现在的“自动驾驶”并发模式，看看 React 是如何从一只“暴躁的火柴人”进化成一只“优雅的章鱼”的。
准备好了吗？把你的咖啡放下，咱们开始。
第一部分：那个“同步”的噩梦时代（React 16 之前）
在很久很久以前，在 React 还是个小鲜肉的时候，它的 setState 是个急性子。
那时候的 setState，在开发模式下，简直就是个疯子。你点一下按钮，它就跑；你点两下，它就跑两次。它根本不管你是不是想一次性改三个状态，它觉得你给什么它就改什么。
让我们看看那个时代的代码。假设你有一个计数器，你想在点击按钮的时候，同时修改 count 和 message。
// 早期 React 代码
class Counter extends React.Component {
constructor(props) {
super(props);
this.state = { count: 0, message: 'Hello' };
}
handleClick() {
// 你以为这会渲染一次？
this.setState({ count: 1 });
this.setState({ count: 2 });
this.setState({ message: 'World' });
}
render() {
return <button onClick={() => this.handleClick()}>Click Me</button>;
}
}运行结果：
你以为 count 会变成 2，message 会变成 ‘World’。但在早期版本里，React 会给你渲染 3次！
第一次渲染：count 变成 1。
第二次渲染：count 变成 2。
第三次渲染：message 变成 ‘World’。
这简直是灾难！ 想象一下，如果你的渲染函数里包含了复杂的动画，或者涉及到了 API 请求，这三次渲染就像是你的电脑同时开了三个 4K 视频，CPU 直接烧了。
为什么？因为那时候 React 的渲染是同步的。setState 一调用，渲染队列立马排好，立刻执行。
专家点评：
早期的 React 就像个没长大的孩子，情绪非常外露。你给它一点糖（调用一次 setState），它就高兴得跳起来（渲染一次）。这种“即时满足”虽然看起来爽快，但性能极差。
第二部分：异步的挣扎与“手动挡”批处理（React 16/17）
为了解决性能问题，React 的核心团队开始意识到：“嘿，这孩子太冲动了，咱们得让他学会等待。”
于是，React 16 引入了异步渲染的概念。虽然那时候还是实验性的，但方向对了。
现在，在事件处理函数里，React 开始尝试把多次 setState 合并成一次渲染。
// React 16/17 事件处理函数
handleClick() {
this.setState({ count: 1 });
this.setState({ count: 2 });
this.setState({ message: 'World' });
}运行结果：
现在，它只渲染 1次。count 变成了 2，message 变成了 ‘World’。完美！
但是！React 虽然变乖了，但它还是有“盲区”。
如果你在 setTimeout、Promise 或者 原生 DOM 事件（比如 window.addEventListener）里面调用 setState，React 就会彻底破功。它依然会一次性触发多次渲染。
class BadTiming extends React.Component {
state = { count: 0 };
componentDidMount() {
// 嘿，React，我是个定时器，我不属于你的圈子
setTimeout(() => {
this.setState({ count: 1 });
this.setState({ count: 2 });
}, 0);
}
render() {
return <div>{this.state.count}</div>;
}
}运行结果：
这里会渲染 2次！count 最终是 2，但中间经历了一次 1。
这就像什么呢？就像你在排队结账，前面有个人在跟收银员吵架（事件处理函数），收银员（React）学会了把后面的单子攒在一起算。但是，如果你突然冲进来一个外卖员（setTimeout），扔下一堆单子就走，收银员就得重新开始手算，不能攒单了。
为了解决这个问题，React 16.3 引入了一个隐藏的 API：unstable_batchedUpdates。
这个 API 就像是一个“强制排队员”。你把你的代码包在它里面，它就会强行把所有的状态更新都归拢到一起。
import { unstable_batchedUpdates } from 'react-dom';
// 早期的“手动批处理”
unstable_batchedUpdates(() => {
this.setState({ count: 1 });
this.setState({ count: 2 });
});运行结果：
无论你在哪里调用，它都只渲染 1次。
专家点评：
这是 React 的“手动挡”时代。虽然好用，但很麻烦。你每次写代码都得小心翼翼，生怕忘了包在 unstable_batchedUpdates 里。而且，这个 API 名字里的 unstable（不稳定）就暗示了它随时可能变。
第三部分：并发模式与“自动驾驶”时代（React 18+）
到了 React 18，事情发生了翻天覆地的变化。React 官方推出了并发模式。
并发模式是什么？简单说，就是 React 学会了“插队”。它可以暂停当前的渲染，去处理更高优先级的任务（比如用户正在输入的文字），然后再回来继续刚才没干完的活。
而批处理，也随之迎来了它的终极进化——自动批处理。
在 React 18 中，React 智能地接管了整个事件循环。它不再只盯着事件处理函数，它开始主动捕捉那些原本不属于它的状态更新。
我们来看看现在的代码。即使是在 setTimeout 里，React 也能搞定。
import React, { useState, useEffect } from 'react';
function AutoBatchingDemo() {
const [count, setCount] = useState(0);
const [flag, setFlag] = useState(false);
useEffect(() => {
// 现在的 React 18：自动批处理！
setTimeout(() => {
setCount(c => c + 1);
setCount(c => c + 1);
setFlag(true);
console.log('Batched inside setTimeout');
}, 0);
}, []);
return (
<div>
<p>Count: {count}</p>
<p>Flag: {flag.toString()}</p>
</div>
);
}运行结果：
这里只渲染 1次！count 增加了 2，flag 变成了 true。
不仅如此，连 Promise 的回调也逃不掉。
useEffect(() => {
fetch('/api/data')
.then(() => {
setCount(c => c + 1);
setFlag(true);
});
}, []);还有 requestAnimationFrame。
还有 原生 DOM 事件。
专家点评：
React 18 的自动批处理就像是一个贴心的管家。无论你是通过什么方式触发的状态更新（只要你是在 React 的“管辖范围”内），管家都会把它们打包在一起，交给 React 处理。
这极大地简化了我们的代码。我们不再需要手动去调用 unstable_batchedUpdates 了，这简直是开发者的福音。
第四部分：深入剖析——触发时机与底层原理
既然自动批处理这么好用，那它到底在什么时候触发？React 是怎么知道什么时候该批处理，什么时候不该批处理的？
这涉及到 React 内部的一个核心概念：批处理上下文。
1. React 事件系统
这是最常见的情况。当你使用 JSX 写的 onClick、onChange 时，React 会自动将它们包装在事件监听器中。在这个监听器内部，React 会设置一个标记，告诉调度器：“嘿，我现在正在处理一批更新。”
2. Promise 链
当你使用 Promise.then 或者 async/await 时，React 也会介入。在 await 之后的代码块中，React 会检测到状态更新，并将其加入当前批处理上下文中。
3. 原生 DOM 事件
如果你在 window.addEventListener('click', ...) 里写代码，React 18 也能识别。这得益于 React 的新事件系统。
4. React 内部调度
React 18 引入了 Scheduler 库。这是一个调度器，它负责管理任务的优先级。当任务进入调度器时，它会检查当前的批处理上下文。如果有上下文，它就会把任务“挂起”或者“排队”，直到上下文结束。
5. 哪里不触发批处理？
有一个著名的“例外”：flushSync。
有时候，我们需要强制 React 不批处理，而是立即渲染。比如，你提交表单时，需要立即把按钮变成“加载中”，同时更新数据，但你不能让按钮的加载状态等到下一次渲染才出现。
这时候，我们需要使用 ReactDOM.flushSync。
import { flushSync } from 'react-dom';
function SubmitButton() {
const [isSubmitting, setIsSubmitting] = useState(false);
const [data, setData] = useState(null);
const handleSubmit = () => {
setIsSubmitting(true); // 这一步会立即触发渲染，把按钮变灰
// 我们必须立即更新数据，不能等批处理
flushSync(() => {
setData({ id: 123, name: 'Alice' });
});
// 这里的逻辑是：先渲染 Loading，再渲染数据
};
return (
<button onClick={handleSubmit} disabled={isSubmitting}>
{isSubmitting ? 'Submitting...' : 'Submit'}
</button>
);
}专家点评：
flushSync 是一把双刃剑。它破坏了批处理的性能优势，强制同步执行。所以，只有在绝对必要时（比如需要强制更新 DOM 以触发副作用），才用它。大多数时候，让 React 自己批处理，它会给你省下不少性能开销。
第五部分：并发模式下的“时间切片”与批处理
这是最酷的部分。在并发模式下，批处理不仅仅是“合并多次渲染”，它还涉及到“中断”和“恢复”。
想象一下，你正在执行一个复杂的计算，更新了 100 个状态。在旧版本里，React 会一口气跑完，可能造成主线程卡顿，导致页面掉帧。
但在并发模式下，React 会利用 Scheduler 把这个大任务切成无数个小块。
// 并发模式下的批处理
function ComplexComponent() {
const [items, setItems] = useState(new Array(1000).fill(0));
const handleClick = () => {
// 这里的批处理是“智能”的
setItems(prev => prev.map(item => item + 1));
setItems(prev => prev.map(item => item + 1));
// ... 更多更新
};
return <button onClick={handleClick}>Add 1000 Items</button>;
}React 会把这几次 setState 放在一个“渲染事务”里。然后，它可能会执行 10 毫秒，然后暂停，去检查有没有更高优先级的任务（比如键盘输入）。如果没有，它再回来继续渲染剩下的部分。
这种机制保证了即使在批处理大量状态更新时，页面也不会卡死。
专家点评：
并发模式下的批处理，就像是在跑马拉松。旧版本是让你一口气冲到终点（可能导致抽筋/崩溃）。新版本是让你跑一会儿，休息一会儿，喝口水，再跑一会儿。虽然总时间差不多，但体验好太多了。
第六部分：实战中的坑与技巧
虽然自动批处理很棒，但我们在实战中还是会遇到一些坑。作为专家，我得给你们提个醒。
坑一：控制台日志的误导
你可能会发现，有时候你在 handleClick 里写了很多 setState，控制台显示渲染了 1 次，但你在 console.log 里看到的却是状态分步变化的值。
这是因为 console.log 执行的时机早于 React 的批量更新。React 是在函数执行完之后才把状态合并的。
handleClick() {
this.setState({ count: 1 });
console.log(this.state.count); // 输出可能是 0
this.setState({ count: 2 });
console.log(this.state.count); // 输出可能是 0
// 渲染后，count 变成了 2
}技巧： 想要看合并后的状态，最好在 useEffect 里打印，或者在渲染函数里打印。
坑二：副作用里的更新
在 useEffect 里更新状态，通常也是会被批处理的。但是，如果你在 useEffect 里依赖了某个值，而这个值在批处理中改变了，可能会导致无限循环或者不符合预期的行为。
useEffect(() => {
const timer = setInterval(() => {
setCount(c => c + 1);
}, 1000);
return () => clearInterval(timer);
}, []); // 空依赖这里，每次渲染都会触发 setInterval 的清理和创建。虽然这是批处理，但 React 的生命周期管理非常严格，它会把清理函数看作一种“副作用”，并在下一次渲染前执行。这可能会导致一些奇怪的闪烁。
坑三：第三方库的“不兼容”
虽然 React 18 的自动批处理覆盖面很广，但并不是所有第三方库都适应了。有些老旧的库可能还在依赖 unstable_batchedUpdates 或者直接操作 DOM。
如果你的应用崩溃了，或者某个库不工作，试着检查一下是不是它破坏了 React 的批处理上下文。
第七部分：未来展望
React 的批处理进化史，其实就是 React 性能优化的进化史。
从最早的同步渲染（性能差，容易卡顿），
到中期的手动异步批处理（性能提升，但开发体验差），
再到现在的自动并发批处理（性能极致，开发体验极佳）。
未来，React 可能会进一步发展。也许我们会看到基于优先级的细粒度批处理。也就是说，不是所有的更新都是平等的。一个用户输入的更新，应该比一个后台数据刷新的更新拥有更高的批处理优先级。
甚至，可能会出现自定义批处理。允许开发者根据业务逻辑，定义什么样的更新应该被批处理在一起。
结语
好了，伙计们。
React 批处理的进化，就像是从骑自行车上班，变成了坐上了自动驾驶的特斯拉。
以前，你需要自己掌握平衡，时刻注意路况（手动批处理），一旦刹车失灵（没批处理），就会摔得鼻青脸肿（页面卡死）。
现在，React 系统帮你处理了所有的路况，你只需要专注于享受驾驶（写业务逻辑）。
记住，虽然自动批处理很方便，但作为专家，你依然需要理解它的原理。当你遇到性能问题时，知道是批处理没生效，还是调度器出了问题，这能帮你节省大量的调试时间。
下次当你看到控制台里只有一个渲染日志时，不要惊讶，那是 React 在向你敬礼，因为它刚刚帮你省下了一次昂贵的渲染成本。
下课！
（偷偷说：如果你觉得这篇文章有用，别忘了给 React 的核心团队点个赞，毕竟他们为了让你少写几行代码，头发都掉光了。）