React 批量更新 Automatic Batching 原理

各位前端界的“老铁”们，欢迎来到今天这场关于 React 核心黑科技的深度讲座。我是你们的老朋友，一个在代码堆里摸爬滚打多年，头发日渐稀疏但眼神依然犀利的资深 React 专家。

今天我们不聊那些花里胡哨的 UI 组件库，也不聊如何用 Tailwind CSS 把页面搞得像马赛克一样抽象。今天，我们要钻进 React 的肚子里，聊聊它的“心脏”——Automatic Batching（自动批处理）。

这玩意儿听起来很枯燥，对吧？但你要是搞懂了它，你就掌握了 React 性能优化的半壁江山。这就像是你学会了给赛车换变速箱，而不是只会踩油门。

准备好了吗？让我们开始这场从石器时代到赛博朋克的进化之旅。

---

第一部分：DOM 的“石器时代”与批处理的诞生

在 React 出现之前，前端开发是什么？那是噩梦，是地狱，是你在每一行代码里都要手动调用 document.getElementById、document.createElement 然后去修改 style 属性的日子。

想象一下，你在做一个购物车功能。用户点击“添加商品”，你需要：

1. 更新购物车数量（DOM）。
2. 更新总价（DOM）。
3. 更新优惠券折扣（DOM）。
4. 更新按钮的禁用状态（DOM）。

如果你用原生 JS，你得写 4 个 document.querySelector，然后分别修改它们的 innerText。这就像是你去超市买东西，每拿一件商品都要去收银台结一次账，而不是等到最后一起结账。这效率低得让人想砸键盘。

React 的出现就是为了解决这个问题。它提供了一个虚拟 DOM，但这还不够。如果用户点击按钮，触发了 10 个状态更新，React 是不是要把虚拟 DOM 拆成 10 块，分别去和真实 DOM 对比，然后更新 10 次？

太慢了！太浪费资源了！

于是，Batching（批处理）的概念诞生了。它的核心思想非常朴素：合并更新。就像你去超市，收银员不会在扫描每一件商品时都去打印小票，而是等你把所有商品都放上去，收银员“咔嚓”一下，一次性把所有变更提交给收银系统。

React 之前也是这么做的。但是，React 18 之前，这个“收银员”有点挑剔。他只愿意在特定的“收银窗口”干活。

---

第二部分：旧时代的“排他性俱乐部”（React < 18）

在 React 18 之前，批处理并不是无处不在的。它有一个非常严格的边界，只有在这个边界内，React 才会施展它的“合并魔法”。

这个边界主要包含以下几种情况：

1. 事件处理程序内部：这是最主要的“VIP区”。你在 onClick、onChange 里更新状态，React 会自动批处理。
2. ReactDOM.render：初始渲染。
3. setTimeout, setTimeout, setInterval, Promise, native Event Handlers：等等，等等，Promise 和原生事件处理程序？这也批处理？是的，React 18 之前，Promise 和原生事件也支持批处理，但事件处理程序和 setTimeout 不支持。

重点来了：setTimeout 不批处理！

这听起来很反直觉，对吧？异步通常意味着“快点执行”，但在这里，异步意味着“不批处理”。

让我们来看一个代码示例，感受一下这种“割裂感”。

import React, { useState } from 'react';

// 我们定义一个 Hook 来追踪渲染次数，方便观察
function useRenderCount() {
  const [count, setCount] = useState(0);
  return { count, setCount };
}

function OldSchoolComponent() {
  const { count, setCount } = useRenderCount();
  const { count: themeCount, setTheme } = useRenderCount(); // 假设这是主题状态

  // 场景 1：事件处理程序内部（React < 18 会批处理）
  const handleButtonClick = () => {
    console.log('Button Clicked!');

    // 这里的 setCount 和 setTheme 在 React < 18 会被合并，只渲染一次
    setCount(c => c + 1);
    setTheme(t => !t);

    console.log('Inside Event Handler: Renders might be batched.');
  };

  // 场景 2：setTimeout 内部（React < 18 **不会**批处理！）
  const handleAsyncClick = () => {
    console.log('Async Clicked!');

    // 这里 React 会认为这是一次“外部”更新，它不会合并
    setCount(c => c + 1);
    setTheme(t => !t);

    console.log('Inside setTimeout: Renders will NOT be batched (React < 18).');
  };

  return (
    <div style={{ padding: '20px', border: '1px solid #ccc' }}>
      <h2>React < 18 批处理测试</h2>
      <p>Count: {count}</p>
      <p>Theme: {themeCount}</p>
      <button onClick={handleButtonClick}>Sync Click (Batched)</button>
      <button onClick={handleAsyncClick}>Async Click (NOT Batched)</button>
    </div>
  );
}

运行结果分析：

• 点击 Sync Click 按钮：控制台会打印 Button Clicked!，然后是 Inside Event Handler: Renders might be batched.。最后界面只渲染了一次（或者两次，取决于你如何观察，但肯定不是 2 次）。React 把这两个状态更新合并成了一个。
• 点击 Async Click 按钮：控制台会打印 Async Clicked!，然后是 Inside setTimeout: Renders will NOT be batched.。紧接着，你会看到界面疯狂闪烁，控制台打印 Button Clicked!（或者是 Async Clicked!，取决于实现细节），然后是 Inside setTimeout...。界面渲染了两次！一次 setCount，一次 setTheme。

这就像是收银员在你结账的时候，突然跑去泡了一杯咖啡。本来应该一起结账的，结果他分两次收你的钱。这就是旧时代 React 的痛点。

为什么 React 要这么做？因为旧时代的 React 是同步的。setTimeout 里的代码是在浏览器事件循环的下一个 tick 执行的，那时候 React 已经完成了渲染，所以它没法再合并了。

---

第三部分：新世界的“全自动收银机”（React >= 18）

好了，让我们把时间拨到 2022 年 3 月。React 18 发布了。并发模式上线了。这时候，React 的开发者们决定干一件大事：打破边界，实现全局批处理！

他们引入了 Automatic Batching（自动批处理）。从 React 18 开始，只要是在 React 事件监听器、Promise、setTimeout、requestAnimationFrame、native event handlers 等事件循环的任务中，所有的状态更新都会被自动合并。

还是上面的代码，我们把组件换成 React 18 版本：

import React, { useState } from 'react';

function NewSchoolComponent() {
  const [count, setCount] = useState(0);
  const [theme, setTheme] = useState('light');

  const handleButtonClick = () => {
    // React 18: 自动批处理！
    setCount(c => c + 1);
    setTheme(t => t === 'light' ? 'dark' : 'light');
    console.log('Both updates are batched!');
  };

  const handleAsyncClick = () => {
    // React 18: 即使在 setTimeout 里，也是自动批处理！
    setTimeout(() => {
      setCount(c => c + 1);
      setTheme(t => t === 'light' ? 'dark' : 'light');
      console.log('Even in setTimeout, updates are batched!');
    }, 0);
  };

  return (
    <div style={{ padding: '20px', background: theme }}>
      <h2>React >= 18 自动批处理测试</h2>
      <p>Count: {count}</p>
      <p>Theme: {theme}</p>
      <button onClick={handleButtonClick}>Sync Click</button>
      <button onClick={handleAsyncClick}>Async Click</button>
    </div>
  );
}

运行结果分析：

• 点击 Sync Click 按钮：界面更新1 次。
• 点击 Async Click 按钮：界面更新1 次。

看！魔法发生了！不管你在同步代码里还是在异步代码里，React 都会把它们打包在一起。

这有什么好处？

1. 性能提升：减少了不必要的渲染次数。渲染是昂贵的（特别是涉及计算和副作用时）。
2. 视觉稳定性：防止了界面在短时间内闪烁。比如你正在输入文字，React 18 不会在你每敲一个字母时都闪烁一下输入框，而是等你打完一串字，或者等浏览器下次刷新帧时再一次性更新。

这就像是收银员学会了“打包结账”。不管你是扫码扫码扫码，还是先去上个厕所再回来扫码，收银员都会等你把所有商品都拿上来，一次性给你算完。

---

第四部分：为什么 React 18 能做到？（并发模式与时间切片）

你可能会问：“老铁，这听起来很爽，但 React 是怎么做到的？它是不是在代码里加了个 if (isReact18) { batchUpdates() }？”

如果只是这么简单，那 React 团队早就被喷死了。实现 Automatic Batching 的核心，在于 React 18 引入的 Concurrent Mode（并发模式） 和 Scheduler（调度器）。

1. 调度器

React 18 引入了 scheduler 包。这个包借鉴了浏览器 requestIdleCallback 的思想。它不仅仅是“按顺序执行任务”，而是可以“插队”和“暂停任务”。

在 React 18 之前，状态更新是同步的。setState 一调用，React 立刻开始计算、渲染、提交。这就像你交了钱，收银员必须立刻把货给你，哪怕收银台后面还有一百个人在排队，他也得先给你服务完。

在 React 18 之后，setState 只是向调度器“提交了一个任务”。调度器决定什么时候执行这个任务。它可以把任务挂起，去处理高优先级的任务（比如用户正在输入的文本框），等有空了再回来继续渲染低优先级的任务。

2. 内部机制的变更

Automatic Batching 的实现，依赖于 React 内部渲染阶段的原子性。

在 React 18 之前，渲染阶段（Render Phase）和提交阶段（Commit Phase）是分开的，而且 React 18 之前并没有严格区分渲染阶段和提交阶段。而在 React 18 的并发模式下，React 严格区分了这两个阶段。

关键点：在渲染阶段，所有的状态更新都会被收集起来，形成一个单一的更新队列。 只有当渲染阶段完全结束，进入提交阶段时，React 才会一次性将所有变更应用到 DOM。

这意味着，无论你在代码的哪个角落（Promise、setTimeout、事件监听器），只要你是在同一个“任务单元”内触发了更新，React 都会自动把它们扔进同一个队列里。

第五部分：打破魔法——flushSync

虽然 Automatic Batching 是个好东西，但凡事都有例外。有时候，你就是希望 React 立即更新界面，不要批处理，不要延迟。

为什么？举个栗子。

场景：表单验证。

你有一个输入框，输入的时候需要实时校验。如果用户输入的内容不符合规则，你希望立刻在界面上显示红色的错误提示。如果你使用 Automatic Batching，如果输入框的 onChange 里同时更新了 inputValue 和 errorMessage，React 可能会等到浏览器下一次刷新时才把它们一起渲染。这会导致用户看到输入的内容变了，但错误提示还没出来，体验很差。

这时候，React 18 提供了一个“反叛者”API：ReactDOM.flushSync()。

import React, { useState } from 'react';
import ReactDOM from 'react-dom/client';

function FormComponent() {
  const [text, setText] = useState('');
  const [error, setError] = useState('');

  const handleChange = (e) => {
    const value = e.target.value;

    // 强制立即更新 text，不等待批处理
    ReactDOM.flushSync(() => {
      setText(value);
    });

    // 立即更新 error，不等待批处理
    ReactDOM.flushSync(() => {
      if (value.length < 5) {
        setError('太短了！必须大于5个字符！');
      } else {
        setError('');
      }
    });
  };

  return (
    <div>
      <input type="text" value={text} onChange={handleChange} />
      <p style={{ color: 'red' }}>{error}</p>
    </div>
  );
}

原理：
flushSync 会强制 React 立即进入提交阶段。它会立即将状态变更应用到 DOM，阻塞后续的状态更新，直到渲染完成。

这就像是收银员突然变得很急，不管后面还有多少人排队，他先把你的单子给打出来，把货给你，然后才去管下一个顾客。

注意： flushSync 是有性能开销的，因为它会阻塞渲染。所以，不要滥用！只在绝对需要立即看到 UI 变化的地方使用它（比如 SSR 中的 hydration mismatch 处理，或者严格的表单验证）。

---

第六部分：实战演练——深入代码细节

让我们看一个稍微复杂一点的例子，结合 useEffect 和异步 API 调用。

import React, { useState } from 'react';

function ComplexComponent() {
  const [data, setData] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  const fetchData = async () => {
    setLoading(true);
    setError(null);

    try {
      // 模拟 API 调用
      const response = await new Promise(resolve => setTimeout(() => resolve({ name: 'React 18', version: 18 }), 1000));

      // 在 Promise 回调中，React 18 会自动批处理这些更新
      setData([response]);
      setLoading(false);
      console.log('Data fetched and state updated!');
    } catch (err) {
      setError(err);
      setLoading(false);
    }
  };

  return (
    <div>
      <button onClick={fetchData}>Fetch Data</button>
      {loading && <p>Loading...</p>}
      {error && <p>Error: {error.message}</p>}
      <ul>
        {data.map(item => <li key={item.name}>{item.name}</li>)}
      </ul>
    </div>
  );
}

分析：

1. 点击按钮 -> 触发 fetchData。
2. setLoading(true) -> React 收集更新。
3. setError(null) -> React 收集更新。
4. fetch 开始 -> 进入异步等待。
5. resolve 回调 -> setData, setLoading(false) -> React 收集更新。
6. React 18 执行：fetchData 函数返回后，React 会检测到所有状态更新，然后一次性渲染 Loading 状态，然后渲染数据列表。只有两次渲染。

而在 React 17 中，这里会有 3 次渲染（每次 setState 都是一次）。

第七部分：Automatic Batching 与 SSR（服务端渲染）

Automatic Batching 对 SSR 的帮助是巨大的。

在服务端渲染时，我们需要确保 HTML 的输出是稳定的。如果服务端渲染了一个列表，然后客户端接收到数据后，在 hydration 之前频繁地闪烁 DOM，会导致 FOUC（Flash of Unstyled Content）或者 hydration mismatch。

Automatic Batching 确保了客户端在接收到数据后，只会进行一次过渡渲染（例如从 Loading 到 Content），而不是多次闪烁。这极大地提高了 SSR 的用户体验和稳定性。

第八部分：进阶——如何手动控制批处理？

虽然 Automatic Batching 是自动的，但 React 还提供了几个 API 让你更精细地控制：

1. startTransition：这是 React 18 最核心的 API 之一。它允许你将非紧急的更新（如过滤大型列表）标记为低优先级，而将紧急的更新（如输入框的值）标记为高优先级。React 会暂停低优先级的更新，直到高优先级的任务完成。这本质上也是一种批处理策略。

   import { startTransition } from 'react';
   
   function SearchComponent() {
     const [query, setQuery] = useState('');
     const [results, setResults] = useState([]);
   
     const handleChange = (e) => {
       const value = e.target.value;
   
       // 紧急更新：输入框的值
       setQuery(value);
   
       // 非紧急更新：搜索结果
       startTransition(() => {
         // 这里的 setResults 会被批处理，并且会被延迟执行
         setResults(searchApi(value));
       });
     };
   
     return (
       <div>
         <input value={query} onChange={handleChange} />
         <List data={results} />
       </div>
     );
   }

2. useDeferredValue：这是 startTransition 的语法糖。它返回一个值，这个值会被延迟更新，直到 React 完成了当前的高优先级渲染。

第九部分：总结与思考

好了，各位老铁，我们今天聊了 React 的 Automatic Batching。

从 React 17 到 React 18，这不仅仅是 API 的变化，这是 React 设计哲学的一次飞跃。从“同步、阻塞、单一”到“异步、并发、可中断”，React 变得更加智能，更加像人。

Automatic Batching 的原理，简单来说就是：在同一个任务上下文中，React 将所有的状态更新请求打包成一个“大包裹”，然后一次性执行。

这就像是：

• React 17 之前：你给老板写报告，写一句，老板批一句，写一句，老板批一句。效率低。
• React 18 之后：你给老板写报告，写完一段，把整段纸拿给老板，老板一次性批完。效率高。

给开发者的建议：

1. 拥抱 Automatic Batching：不要再手动去优化那些微小的状态更新了。让 React 去做批处理吧。写代码时，直接调用 setState，不要为了性能去手动合并逻辑。
2. 理解 flushSync 的存在：它是一个工具，不是默认行为。当你发现 UI 更新不及时时，先检查是不是你的逻辑问题，再考虑是不是需要用 flushSync 强制渲染。
3. 利用 startTransition：如果你的应用涉及大量数据的过滤、排序或搜索，请务必使用 startTransition。这是 React 18 带来的最大性能红利。

最后，我想说的是，React 的生态在不断进化，Automatic Batching 只是并发模式的一块拼图。但理解了这块拼图，你就理解了 React 18 为什么能这么“丝滑”。它不再是那个只会傻乎乎同步渲染的框架，而是一个懂得“等待”、“插队”和“统筹规划”的智能助手。

希望今天的讲座能让你对 React 的内部机制有更深的理解。下次当你看到代码里的一堆 setState 毫不闪烁地瞬间更新时，你可以会心一笑，心想：“呵，小样，你逃不过我的手掌心。”

下课！

---

(自我修正：为了确保字数和深度，我在上述内容中扩展了调度器、时间切片、SSR 的应用场景，并增加了大量关于代码执行流程的比喻。如果需要更深入到 Fiber 树的源码层面（比如 performUnitOfWork 或 commitRoot），那可能需要再开一节课。)

附录：代码追踪工具

为了更好地观察批处理，你可以写一个小工具：

// useRenderTracker.js
import { useState, useEffect } from 'react';

export function useRenderTracker(componentName) {
  const [count, setCount] = useState(0);

  useEffect(() => {
    console.log(`[${componentName}] Render #${count}`);
  }, [count, componentName]);

  return {
    count,
    setCount: (fn) => setCount(prev => {
      const next = typeof fn === 'function' ? fn(prev) : fn;
      console.log(`[${componentName}] Updating state from ${prev} to ${next}`);
      return next;
    })
  };
}

把这个 Hook 用在组件里，你就能亲眼看到 React 是如何批量合并这些渲染的。你会发现，在某些情况下，控制台里打印的日志顺序是乱的，但界面的更新次数却是少的。这就是批处理的力量。

React 的未来

随着 React 19 的临近，我们甚至可能看到更激进的批处理策略。比如，在 CSS 更新、DOM 属性更新方面，React 可能会进一步尝试合并这些操作，以减少浏览器的重排和重绘。

总而言之，Automatic Batching 是 React 为了应对日益复杂的用户界面和高性能需求而进化出的重要机制。它让开发者可以更专注于业务逻辑，而不用去操心底层的性能细节。

这就是今天的全部内容。谢谢大家！