引言：一次 state 更新引发的性能反思
在 React 中，调用 setState 会触发组件更新，这一点似乎人人皆知。但你是否注意过这样一个细节：
setCount(count + 1);
setName('张三');
这两次状态更新是否触发了两次组件重新渲染？
大多数情况下，并不会。React 背后有一套“批处理机制（Batching） ”来智能合并多次更新，从而避免性能浪费。
但这个机制并非总是如你所想。比如在某些异步逻辑中，它又失效了：
setTimeout(() => {
setCount(count + 1); // 此时可能触发独立渲染
setName('李四');
}, 0);
这背后到底发生了什么？React 是如何判断要不要批处理？Fiber 又扮演了什么角色？
让我们一起揭开批处理的面纱。
一、什么是 React 的批处理（Batching）？
批处理是指：将多个状态更新合并为一次重新渲染过程，避免重复执行虚拟 DOM diff、更新、重绘等昂贵操作。
通俗来说，就是把多个 setState 聚在一起，一次性更新 UI。其目的显而易见：
- 减少重新渲染次数
- 降低性能开销
- 提高响应效率
示意图：
普通模式：
setState A -> render
setState B -> render
setState C -> render
批处理模式：
setState A
setState B
setState C
=> render（一次）
在 React 的设计哲学中，这种机制是提升 UI 性能的核心之一。
二、React 早期批处理机制（< React 18）
在 React 18 之前，React 仅在“合成事件”、“生命周期钩子”中自动进行批处理。
例如：
function handleClick() {
setA(1);
setB(2); // ✅ 会批处理更新
}
这是因为 React 控制了 handleClick 的事件调度环境，知道可以安全地将多次更新聚合到一个更新周期中。
但如果是异步环境（如 setTimeout, Promise.then）：
setTimeout(() => {
setA(1);
setB(2); // ❌ 会触发两次 render
});
React 不知道你打算何时结束更新，因此无法安全合并，这就导致了批处理“失效” 。
三、React 18 的自动批处理（Automatic Batching）
React 18 引入了自动批处理（Automatic Batching） ，极大扩展了批处理的适用范围。
✅ 支持异步环境批处理
setTimeout(() => {
setA(1);
setB(2); // ✅ React 18 会自动批处理这两个更新
});
这背后是 React 18 对调度环境的控制能力增强了，通过 新的并发更新模型（Concurrent Mode） 和 调度器 Scheduler，使得批处理延伸到 Promise、timeout、fetch 等异步任务中。
只要你使用的是
createRoot而不是ReactDOM.render，就能启用自动批处理能力。
import { createRoot } from 'react-dom/client';
const root = createRoot(document.getElementById('root'));
root.render(<App />);
四、React 如何实现批处理？
从源码层面理解，我们可以把批处理看作由以下几层结构组成：
1. batchedUpdates 函数：调度封装器
ReactDOM.unstable_batchedUpdates 是早期提供的批处理接口，React 内部用它来包裹事件回调等。
import { unstable_batchedUpdates } from 'react-dom';
unstable_batchedUpdates(() => {
setA(1);
setB(2); // ✅ 确保手动批处理
});
在 React 18 中，这已经封装进了更高级的调度器机制中。
2. flushSync：强制同步更新
有时你想让更新立即生效，可以使用：
import { flushSync } from 'react-dom';
flushSync(() => {
setA(1); // 👈 会立即更新
});
注意：使用 flushSync 可能打断批处理，不建议在非必要场景使用。
3. Fiber 架构如何处理更新
Fiber 是 React 的协调引擎（Reconciler），它本身就是异步、可中断的。
每次状态更新，Fiber 都会创建一个“更新任务”（Update），放入队列中，直到触发 render，才统一处理这些更新。
更新队列结构大致如下：
interface Update {
lane: Lane; // 优先级
payload: any; // setState 的数据
callback?: () => void;
}
而批处理就是“在合适的时间，将这些 update 一次性 flush（冲刷）出去”。
五、批处理的边界与误区
虽然 React 的批处理机制越来越智能，但仍存在一些边界和注意事项。
❌ React 18 的批处理不是万能的
window.addEventListener('click', () => {
setA(1);
setB(2);
});
这是浏览器原生事件，React 无法拦截调度，因此无法自动批处理。
解决方案：
你可以手动使用 unstable_batchedUpdates：
window.addEventListener('click', () => {
unstable_batchedUpdates(() => {
setA(1);
setB(2);
});
});
✅ 批处理并不影响“更新顺序”
React 批处理合并的是“render 渲染次数”，但不会打乱状态更新顺序：
setCount(prev => prev + 1);
setCount(prev => prev + 1); // count 增加两次，不是一次
这一点对于“函数式更新”尤其重要。
六、为什么批处理如此重要？
性能角度
- 每次渲染会执行 Fiber 树的构建、diff、commit 等流程，代价不小。
- 批处理可以极大减少渲染次数，节省计算与重排开销。
可维护性角度
- 避免“多次 setState 导致组件重复闪烁”
- 有助于状态一致性，减少不必要的中间状态渲染
七、总结
| 特性 | React 17 | React 18 |
|---|---|---|
| 合成事件中批处理 | ✅ | ✅ |
| 生命周期中批处理 | ✅ | ✅ |
setTimeout 中批处理 | ❌ | ✅ |
Promise.then 中批处理 | ❌ | ✅ |
fetch().then 中批处理 | ❌ | ✅ |
| 手动控制批处理 | ✅ | ✅ |
React 的批处理机制是其性能优化的基石之一，从 17 的“有限场景批处理”迈向 18 的“自动批处理”，体现了 React 不断演进的调度策略和架构思维。
结语
React 的批处理机制，不只是性能提升手段，更是构建高质量交互体验的基础。
深入理解批处理原理，能够帮助我们在构建复杂 UI 时更从容应对性能瓶颈、状态一致性、闪烁问题。
下一次你看到 setState，请记住：它背后，其实是一次异步调度的精密操作。
