当多个事件在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 ( { setState2(1); }} onFocus={() => { console.log("focus"); setState(s => { console.log("focus setState", s); return [...s, "focus"]; }); }} /> );}
当用户点击输入框时，onMouseDown会先于onFocus触发。根据代码逻辑，我们可能预期控制台输出如下：
effectfocuseffect setState []focus setState ['effect']
然而，实际观察到的输出可能是：
effectfocusfocus 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 ( { 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"]
从这个输出中，我们可以观察到以下关键点：
mousedown 发生在渲染迭代 1。effect 和 focus 都在渲染迭代 2 中被调用。focus setState 第一次执行发生在渲染迭代 3，此时 state 是 []。紧接着，effect setState 执行，也基于 []，并返回 [‘effect’]。然后，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 回调中包含昂贵的副作用操作，了解它可能被多次执行的特性就变得尤为重要，以便优化或避免不必要的重复计算。
以上就是深入解析React setState 回调的多次执行行为的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1539355.html
微信扫一扫 
支付宝扫一扫 
