useState更新数组状态的最优方案及渲染循环不匹配问题解析

假设我们定义了状态变量：const [numbers, setNumbers] = useState([1,2,3]);，从技术层面来说，更新该状态的首选/最佳方式是什么？为什么？我之前遇到过渲染循环不匹配的问题，虽然已经解决，但希望理解背后的原理。

三个可选实现方式 #

选项1：

setNumbers(numbers.slice(1))

选项2：

setNumbers(state => numbers.slice(1))

选项3：

setNumbers(state => state.slice(1))

正确答案：选项3是最佳实现方式 #

下面从技术原理层面拆解原因：

1. React状态更新的两种模式 #

useState的更新函数支持两种调用逻辑：

• 直接传值：像选项1那样，直接传入新状态值。这种方式依赖当前渲染周期中numbers的快照值，受闭包特性限制。
• 函数式更新：像选项2、3那样，传入一个接收当前最新状态的回调函数，返回计算后的新状态。这是React官方推荐的、依赖前序状态的更新方式。

2. 选项1和2的问题 #

• 选项1的弊端：如果状态更新逻辑依赖numbers（比如在useEffect或连续事件触发中），闭包会捕获渲染时的numbers快照，而非最新状态。当多次连续更新或依赖前序状态结果时，会拿到过时值，导致状态更新不符合预期，甚至触发不必要的渲染循环——比如在useEffect中依赖numbers并更新它，会因numbers变化反复触发useEffect，形成无限循环。
• 选项2的错误：虽然套了函数式更新的壳，但回调里依然用外部的numbers变量，而非回调参数state，本质和选项1一样，完全没利用函数式更新获取最新状态的优势，属于错误用法。

3. 选项3的核心优势 #

选项3的函数式更新完全遵循React的状态更新规范：

• 回调参数state是React保证的当前最新状态，不受闭包快照的影响，每次更新都能基于最新值计算新状态，彻底避免过时状态的问题。
• 当状态更新依赖前一次状态时（比如这里的slice(1)是基于原数组截断），函数式更新是唯一可靠的方式，能确保状态更新的原子性和正确性，从根源上避免渲染循环不匹配的问题。

渲染循环不匹配的原理 #

这类问题通常源于：状态更新依赖了过时的状态值，导致更新后的状态不符合预期，React需要多次渲染修正，或陷入无限渲染。比如用选项1在useEffect中更新状态，同时依赖项包含numbers，每次更新后numbers变化触发useEffect再次执行，又更新状态，形成循环。而选项3的函数式更新不需要在依赖项中添加numbers（因为更新逻辑不依赖外部变量），就能基于最新状态完成更新，从根源切断循环。

内容的提问来源于stack exchange，提问作者Jason Ayer