setState回调多次执行原因详解

最近发现不少小伙伴都对文章很感兴趣，所以今天继续给大家介绍文章相关的知识，本文《React setState回调多次执行原因解析》主要内容涉及到等等知识点，希望能帮到你！当然如果阅读本文时存在不同想法，可以在评论中表达，但是请勿使用过激的措辞~

当多个事件在React应用中快速连续触发状态更新时，`setState` 的回调函数可能会出现多次执行的现象，即使最终状态与预期一致。这与React 18的自动批处理机制以及其处理跨不同意图事件更新的策略有关，并非严格模式下的诊断性双重调用，而是为了确保在潜在的陈旧渲染上基于最新状态进行重新计算。

理解React中setState回调的多次执行现象

在React 18及更高版本中，开发者有时会观察到setState的回调函数在特定场景下被多次调用，即使没有开启严格模式。这种现象尤其在多个事件（如onMouseDown和onFocus）几乎同时触发并导致状态更新时更为明显。本文将深入探讨这一行为背后的原因，并提供如何理解和调试此类问题的洞察。

示例场景与异常观察

考虑以下React组件代码，其中useEffect和两个事件处理器分别触发状态更新：

import React, { useState, useEffect } from "react";

function App() {
  const [state, setState] = useState([]);
  const [state2, setState2] = useState(0);

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

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

当用户点击输入框时，onMouseDown会先于onFocus触发。根据代码逻辑，我们可能预期控制台输出如下：

effect
focus
effect setState []
focus setState ['effect']

然而，实际观察到的输出可能是：

effect
focus
focus setState []        // 第一次 'focus setState'，基于空数组
effect setState []        // 'effect setState'，基于空数组
focus setState ['effect'] // 第二次 'focus setState'，基于 ['effect']

这表明 focus setState 的回调函数被执行了两次，第一次基于空数组 []，第二次基于包含 'effect' 的数组 ['effect']。

调试与行为分析

为了更清晰地追踪每次渲染和状态更新的精确时机，我们可以引入一个渲染计数器和高精度时间戳：

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

const render = React.useRef(0);

function App() {
  render.current++; // 每次渲染时增加计数器

  const [state, setState] = useState([]);
  const [state2, setState2] = useState(0);

  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"];
        });
      }}
    />
  );
}

使用上述修改后的代码，控制台输出将提供更详细的执行流程：

1 2971 "mousedown" 
2 2974 "effect" 
2 2978 "focus" 
3 2978 "focus setState" []           // 渲染迭代 3，基于 []
4 2982 "effect setState" []           // 渲染迭代 4，基于 []
4 2982 "focus setState" (1) ["effect"] // 渲染迭代 4，基于 ["effect"]

从这个输出中，我们可以观察到以下关键点：

1. mousedown 发生在渲染迭代 1。
2. effect 和 focus 都在渲染迭代 2 中被调用。
3. focus setState 第一次执行发生在渲染迭代 3，此时 state 是 []。
4. 紧接着，effect setState 执行，也基于 []，并返回 ['effect']。
5. 然后，focus setState 再次执行，但这次它接收到的 state 是 ['effect']，并返回 ['effect', 'focus']。

React的批处理与跨事件更新

这种行为的关键在于React的批处理机制。React 18引入了自动批处理，它会将同一事件循环或异步操作中的多个状态更新合并为一次渲染，以提高性能。然而，React文档明确指出：

React does not batch across multiple intentional events. (React 不会对多个有意图的事件进行批处理。)

这意味着，像 onMouseDown 和 onFocus 这样由用户交互触发的独立事件，即使它们在时间上非常接近，React 也可能不会将它们的更新完全合并到一个批次中。

当 onMouseDown 触发 setState2(1) 时，它会调度一次更新。随后，onFocus 触发 setState(s => [...s, "focus"])。由于这两个是不同的“意图事件”，React可能会在处理第一个事件的更新后，重新评估并处理第二个事件的更新。

在这种情况下，第一次 focus setState 回调可能是在一个“陈旧”的渲染（迭代 3）上下文中执行的，该上下文中的 state 仍为 []。当 effect 触发的 setState 完成后，state 变成了 ['effect']。由于 onFocus 的更新可能被视为在另一个事件上下文中，或者React为了确保一致性，会检测到第一次 focus setState 的计算是基于一个过时的状态，因此会丢弃第一次的结果并重新运行整个批处理队列（包括 focus setState 的回调），但这次是基于最新的状态 ['effect']。

这与React严格模式下为了帮助开发者发现副作用而将更新器函数运行两次（并丢弃第二次结果）的行为有相似之处，但本质不同。这里，React是为了在多个紧密发生的、独立的事件更新中，确保最终状态的正确性，避免基于陈旧状态进行计算，从而可能重新执行更新器函数。

结论与注意事项

尽管这种多次执行setState回调的现象可能令人困惑，但通常情况下，React能够确保最终的状态是正确的，即与我们预期的一致。在上述例子中，最终 state 将是 ['effect', 'focus']，这正是我们期望的结果。

关键 takeaway：

• 非批处理跨独立事件： React不会对来自不同“意图事件”的更新进行批处理，这可能导致在快速连续触发的事件中，状态更新的协调过程更为复杂。
• 陈旧渲染与重新计算： 当一个状态更新的回调函数在执行时，如果它所依赖的状态快照已经因为其他并发更新而变得陈旧，React可能会重新运行该回调，以确保它基于最新的状态进行计算。
• 最终状态一致性： 尽管回调可能多次执行，React的内部机制旨在保证最终组件状态的正确性。

对于开发者而言，理解这一机制有助于在调试复杂的状态交互时，避免被控制台的多次输出所迷惑。在大多数情况下，无需为此行为进行特殊处理，因为React会负责管理最终的状态一致性。然而，如果 setState 回调中包含昂贵的副作用操作，了解它可能被多次执行的特性就变得尤为重要，以便优化或避免不必要的重复计算。

好了，本文到此结束，带大家了解了《setState回调多次执行原因详解》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！