React setState回调在并发事件中多重执行机制解析

在React 18中，即使禁用严格模式并启用自动批处理，当状态更新在短时间内由不同的“有意事件”（如`onMouseDown`和`onFocus`）以及`useEffect`触发时，`setState`的回调函数可能会被执行多次。这并非错误，而是React为了处理潜在的“陈旧渲染”并确保最终状态一致性而采取的一种内部机制，类似于严格模式下的双重调用，但目的在于丢弃过时的更新结果并重新处理批次。

深入理解React的批量更新与事件处理

React 18引入了自动批处理（Automatic Batching），这意味着在一次浏览器事件（如点击、按键等）或Promise回调中，多个setState调用会被合并成一次渲染，从而优化性能。然而，React的批处理并非无限制的。一个重要的规则是：React 不会对跨越多个“有意事件”（multiple intentional events）的状态更新进行批处理。

这意味着，如果一个用户交互在极短的时间内触发了多个不同的DOM事件（例如，一个元素的onMouseDown和onFocus事件），React会将它们视为独立的事件批次。在这些独立的批次中，如果存在相互依赖或快速连续的状态更新，setState的回调函数就可能出现重复执行的情况。

考虑以下场景：一个input元素同时绑定了onMouseDown和onFocus事件，并且useEffect也依赖于某个状态进行更新。

import React, { useState, useEffect, useRef } from 'react';

function App() {
  const [state, setState] = useState([]);
  const [state2, setState2] = useState(0);
  const render = useRef(0); // 用于追踪渲染次数
  render.current++;

  useEffect(() => {
    if (state2) {
      console.log(render.current, performance.now(), "effect");
      setState(s => {
        console.log(render.current, performance.now(), "effect setState", s);
        return [...s, "effect"];
      });
    }
  }, [state2]);

  return (
    <input
      onMouseDown={() => {
        console.log(render.current, performance.now(), "mousedown");
        setState2(1);
      }}
      onFocus={() => {
        console.log(render.current, performance.now(), "focus");
        setState(s => {
          console.log(render.current, performance.now(), "focus setState", s);
          return [...s, "focus"];
        });
      }}
    />
  );
}

当用户点击input时，onMouseDown通常会先于onFocus触发。我们期望的日志顺序可能是：mousedown -> effect -> focus -> effect setState -> focus setState。然而，实际观察到的日志可能如下（带渲染次数和高精度时间戳）：

1 2971 "mousedown" 
2 2974 "effect" 1
2 2978 "focus" 
3 2978 "focus setState" [] // 第一次执行，基于陈旧的state
4 2982 "effect setState" []
4 2982 "focus setState" (1) ["effect"] // 第二次执行，基于更新后的state

揭示机制：Stale Render与回调的重新执行

从上面的日志可以看出，focus setState的回调函数被执行了两次。第一次在渲染迭代3中，它接收到的是空的[]作为state；第二次在渲染迭代4中，它接收到的是['effect']。这表明React在处理过程中，可能会因为“陈旧渲染”（stale render）而重新执行setState的回调函数。

这种行为与React严格模式（Strict Mode）下updater函数会被调用两次以帮助开发者发现副作用的机制有相似之处，但其根本原因不同。在严格模式下，第二次调用是为了调试并会丢弃结果。而在这种并发事件场景下，React重新执行回调是为了处理由于不同事件批次导致的状态不一致性。

Otter.ai

一个自动的会议记录和笔记工具，会议内容生成和实时转录

91

查看详情

具体来说，当onMouseDown触发并更新state2时，useEffect会随之触发并尝试更新state。紧接着，onFocus事件也触发并尝试更新state。由于这些是“多个有意事件”，React可能不会将它们完全批处理到同一个更新周期。

当第一次focus setState回调执行时（在渲染迭代3），它可能基于一个相对“陈旧”的state快照（即尚未完全反映effect setState更新的快照）。React检测到这种潜在的陈旧性后，为了确保最终状态的正确性，它会丢弃这次陈旧的更新结果，并重新排队或重新执行相关的更新批次。在后续的渲染迭代（例如迭代4）中，focus setState回调会再次执行，这次它将基于最新的、已包含effect更新的state快照，从而产生最终正确的结果。

这种机制是React内部为了维护状态一致性和处理并发更新而采取的保护措施。它确保了即使在快速连续的、非批处理的事件流中，组件的最终状态也能达到预期。

结论与开发实践建议

尽管setState回调的重复执行可能看起来出乎意料，但它通常不会导致最终状态错误，因为React会确保在最终渲染时使用最新的、正确的状态。这种行为是React内部为处理复杂并发更新而设计的鲁棒性体现。

对于开发者而言，理解这一机制有以下几点重要意义：

1. 纯函数原则： 再次强调setState的回调函数（updater function）必须是纯函数。它不应该有副作用，因为React可能会多次调用它并丢弃其结果。
2. 调试复杂状态流： 当遇到状态更新行为难以理解时，引入render计数器和performance.now()等调试工具可以帮助追踪每次渲染和状态更新的精确时机和上下文，从而更好地理解React的内部处理流程。
3. 性能考量： 尽管React会优化处理，但如果setState回调中包含大量计算，重复执行可能会带来轻微的性能开销。在设计状态更新逻辑时，应尽量保持回调函数的简洁高效。
4. 最终一致性： 信任React的最终一致性保证。即使中间过程看起来有些复杂，React也会努力确保组件最终呈现出正确的状态。

总之，setState回调在特定并发事件场景下的多重执行是React内部的一种高级协调机制，旨在确保状态的最终一致性。理解其背后的原理有助于开发者编写更健壮、更可预测的React应用。

以上就是React setState回调在并发事件中多重执行机制解析的详细内容，更多请关注php中文网其它相关文章！