获课：xingkeit.top/5263/

React 18 自动批处理优化购物车：多次状态更新如何变成一次渲染

电商购物车是 React 性能优化的经典战场。用户一次点击"加入购物车"，背后可能同时触发商品数量更新、小计重新计算、优惠金额重算、库存校验等多个状态变更。在 React 17 时代，这些更新如果散落在异步逻辑中，会像多米诺骨牌一样逐个触发渲染——每一次 setState 都是一次完整的 DOM 对比与重绘，性能被无声吞噬。React 18 的自动批处理，正是为终结这场浪费而来。

购物车的痛点：多状态更新为何昂贵

以购物车添加商品为例。点击按钮后，需要更新商品列表、更新总数量、重新计算小计、刷新优惠信息。这四个状态更新如果在 setTimeout、Promise 或原生事件中逐个执行，React 17 会老老实实地渲染四次——组件树遍历四遍、Diff 算法跑四轮、DOM 操作执行四次。用户看到的是按钮点一下，页面"闪"了四下。

更隐蔽的问题在于 useEffect 依赖链。如果小计计算依赖商品列表，而商品列表又依赖库存数据，任何一个中间状态的延迟渲染都会导致后续 useEffect 触发时机错乱，小计数字和商品列表对不上号。

自动批处理的核心：一个事件循环，一次渲染

React 18 的自动批处理将规则从"仅 React 事件内生效"扩展到了所有场景——setTimeout、Promise、fetch 回调、原生事件监听器，全部覆盖。它的实现逻辑并不复杂：当状态更新发生时，React 不会立即执行渲染，而是将更新放入微任务队列。等当前事件循环结束、JavaScript 运行栈清空后，React Scheduler 统一检查队列，把同一轮循环内的所有更新合并，只触发一次渲染。

放到购物车场景里：用户点击添加商品，在同一个事件循环中连续调用了四次 setState。React 18 不会渲染四次，而是把这四个更新打包，一次性计算出最终状态，只渲染一次。组件树只遍历一遍，DOM 只操作一次，性能开销从线性 O(n) 降为常数 O(1)。

实战中的两个关键细节

第一，useEffect 的触发时机变了。 由于批处理将多个更新合并为一次渲染，依赖这些状态的 useEffect 也只会执行一次，且拿到的是最终合并后的值。这意味着购物车的小计计算 useEffect 不再需要手动防抖或去重，React 已经帮你做了。但要注意：useEffect 的依赖数组必须精确，不能漏掉任何一个响应式值，否则合并后的状态变化可能被忽略。

第二，flushSync 是你的逃生口。 绝大多数场景下自动批处理是利好，但如果你需要在状态更新后立即获取 DOM 尺寸——比如购物车浮层需要根据商品总高度动态定位——批处理会让你拿到旧值。这时用 flushSync 包裹更新，强制立即渲染，跳出批处理队列。但这是例外，不是常态，滥用会把性能优化打回原形。

效果有多明显

实测数据最有说服力：在包含上百个商品的购物车中，一次批量添加操作如果触发五个状态更新，React 17 会渲染五次，React 18 只渲染一次。渲染次数从 5 降到 1，DOM 操作减少 80%。配合并发渲染的优先级调度，用户输入搜索关键词时，即使购物车正在做大量计算，输入框的响应也不会被阻塞——高优先级的交互更新会打断低优先级的购物车渲染，确保用户操作永远流畅。

自动批处理不是银弹，但它是 React 18 给所有开发者的一份免费性能礼物。购物车这种多状态联动的场景，恰好是它最擅长的战场。把更新交给 React 去合并，你只需要写清楚"最终状态是什么"，剩下的，框架替你扛。