先记住这个答案
在普通 React 事件处理器中，多次 setter 会被收集并一起处理，使界面通常直接呈现这组更新后的结果，减少逐次提交的开销。它不会把当前处理器中的状态变量原地改成新值，也不意味着每个 setter 都被忽略到只剩最后一个。不同的有意点击通常分别处理，React 需要让前一次交互的结果能够影响下一次交互。严格模式检查、其他更新和并发调度会影响组件函数调用次数，所以“多个 setter 永远只调用组件一次”不是可靠保证。
- 批处理减少一组更新中的中间提交
- 当前事件仍读取本次渲染的状态快照
- 按提交结果验证行为，不把日志次数当成契约
两个字段可以在同一次点击后一起变化
设置面板同时切换是否启用和运行模式，如果每改一个字段就立即提交一次，用户可能短暂看到不完整组合。普通事件批处理使相关更新可以一起推进，示例中第一次点击后显示“启用 / 手动”，第二次点击恢复原组合。
这只是对本次更新安排的说明，不代表任意两个独立 setter 永远能维护业务一致性。若字段之间存在复杂约束，应在状态结构或 reducer 中表达合法转换，不能让批处理承担本来属于数据模型的责任。
import { useState } from 'react';
export default function SettingsToggle() {
const [enabled, setEnabled] = useState(false);
const [manual, setManual] = useState(false);
function toggle() {
setEnabled(value => !value);
setManual(value => !value);
}
return <>
<button onClick={toggle}>切换设置</button>
<output>{enabled ? '启用' : '停用'} / {manual ? '手动' : '自动'}</output>
</>;
}在这个没有额外更新来源的普通事件示例里，一次点击后两个字段一起呈现新值。验收应查看提交后的组合，不把开发模式下组件函数的日志条数当成一次点击的业务次数。
批处理边界不是整个页面存活期间
两个独立点击各自携带用户意图，不能因为发生得很近就假定永远合并。例如第一次点击使提交按钮禁用，后续点击应能观察这个结果；表单不能依靠一个无限延后的批次才决定是否阻止重复操作。
异步回调中的自动批处理还涉及 React 版本与根 API，不能从当前点击示例直接推出所有定时器的旧版本行为。需要比较 Promise、定时器或原生事件时，应明确运行时、入口和测量方式，再解释实际差异。
测量提交而不是在渲染函数里制造计数副作用
render 中修改外部计数器既会污染渲染纯度，也会把开发检查或未提交的尝试记录为用户可见更新。性能分析应使用适当的 Profiler 或提交阶段观测，并把初次挂载与后续点击分开统计。
批处理也不是数据库事务，不能撤销事件中已经发出的网络请求。如果设置更新和远端保存需要一致性，应明确请求身份、失败恢复与界面状态；把两个 setter 放在相邻行不会给外部系统带来原子提交能力。
容易答错的地方
- React 批处理就是只执行最后一条 setter
- 不同状态和函数更新仍会参与计算，批处理协调处理与提交时机。把它理解成删除前面的调用，会错误推导累加和多字段更新结果。
- 看到两条 render 日志就说明自动批处理失效
- 日志可能来自严格模式检查或其他渲染尝试；需要隔离更新来源并观察提交，不能仅凭开发控制台里函数被调用的次数下结论。
面试官还会怎么问？
为什么事件里 setEnabled 后打印还是旧值？
批处理并不修改当前处理器捕获的状态变量，它仍属于本次渲染。下一次渲染会拿到新状态，需要立即使用确定的新值时可另行计算局部变量。
批处理能防止所有重复提交吗？
不能，它只协调 React 更新。请求重试、多个入口和网络状态未知仍可能造成重复动作，需要业务幂等与任务状态判断共同处理。
如果需要在 setter 下一行读取新 DOM 怎么办？
先判断能否改为提交后的正常流程。确有第三方同步集成要求时可考虑 flushSync，但应理解它可能冲刷更多工作并带来性能成本。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。