React事件处理器内函数执行调度：首次setCount同步执行原因

核心结论：你观察到的首次点击时2.1提前打印，不是setState变成同步执行了，这是React调度层优化逻辑在首次更新场景下的特殊表现，属于框架的预期行为。

相关测试代码如下：

const [count, setCount] = React.useState(1);
const handleClick = () => {
  console.log('1');

  setCount((prevCount) => {
    console.log('2.1');
    return prevCount + 1;
  });

  setCount((prevCount) => {
    console.log('2.2');
    console.log('------------');
    return prevCount + 1;
  });

  console.log('3');
}

• 你预期的1 -> 3 -> 2.1 -> 2.2顺序，是React 18+自动批处理的标准逻辑：事件处理器中的同步代码会先全部执行完成，React才会批量处理队列里的所有状态更新，按入队顺序执行函数式更新的回调。后续所有点击都符合这个逻辑，就是因为走的是标准批处理流程。
• 首次点击出现1->2.1->3->2.2的顺序，根因是React的急切更新（Eager Update）优化机制：
  组件挂载完成后第一次触发状态更新时，调度器还未启动工作循环，当前fiber节点也没有待处理的更新队列，此时第一次调用setCount会触发优化判断逻辑：同步执行队首第一个更新的回调函数计算新状态，判断新状态和原状态是否引用一致——如果一致就直接跳过整个更新调度流程，省去不必要的渲染开销。这个同步计算的步骤就会执行第一个setCount的回调，打印出2.1。
  等这个优化校验走完，React发现新状态和原状态不一致，才会正常启动批处理调度，把后续更新加入队列，等handleClick里所有同步代码执行完（也就是打印完3），再执行队列里剩余的更新回调，打印2.2。
• 第一次更新执行完成后，React的事件批处理上下文、调度器工作循环都已经完成初始化，后续再触发状态更新时，所有setState调用会直接进入批处理队列，不会再走首次更新的同步校验路径，所有更新回调都会等事件回调的同步代码执行完再批量触发，就回到了预期的执行顺序。

补充说明：这个过程中setState的异步批处理本质没有变化，你在第一个setCount调用后立刻打印count变量，拿到的仍然是更新前的旧值——因为急切优化阶段执行回调拿到的prevCount是React内部维护的状态副本，更新结果不会同步到当前渲染闭包的count变量上。

内容的提问来源于stack exchange，提问作者Tuan Luu