useEffect闭包为什么会拿到旧state？怎么解决？

一、现象复现：为什么计数器永远卡在 1？

很多初次使用 React Hooks 的开发者，最常遇到该问题的场景便是通过 useEffect 启动一个定时器。我们来看一段常见的计数器代码：

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

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const timer = setInterval(() => {
      // 开发者预期：每秒 +1，依次显示 1, 2, 3, 4...
      // 实际结果：数字从 0 变成 1 后，就永远停留在了 1！
      console.log('当前定时器内读取的 count:', count);
      setCount(count + 1);
    }, 1000);

    return () => clearInterval(timer);
  }, []); // 依赖项传入了空数组

  return <div>当前计数：{count}</div>;
}

运行这段代码时，你会发现页面在第 1 秒时正常跳成了 1，但随后无论过去多久，控制台每秒打印出来的 count 始终是 0，页面上的数字也永远不再递增。许多人下意识会怀疑是否是 setCount 失效或者定时器没有继续运行，但通过控制台日志可以证实，定时器确实在每秒稳定执行，只是它每次计算的算式永远都是 setCount(0 + 1)。

要理解为何会出现这一结果，我们需要从时序上拆解 React 与 JavaScript 闭包的配合过程：

1. 组件初次挂载（Render 1）：组件以 count = 0 执行。React 执行 useEffect，浏览器注册了 setInterval。此时该定时器回调函数诞生在 Render 1 的作用域内，它通过闭包访问并记住了当前的 count，其值为 0。
2. 第 1 秒定时器触发：回调执行 setCount(0 + 1)，计算结果为 1。React 接收到新状态，准备进行下一次渲染。
3. 组件第 2 次渲染（Render 2）：组件以 count = 1 重新运行，JSX 计算出新的 DOM 结构。此时 React 比对 useEffect 的依赖项数组 []，发现依赖未发生任何改变，因此跳过本次 Effect 的重新执行。这意味着第 1 步注册的旧定时器依然在后台运行，新的 Effect 没有被挂载。
4. 第 2 秒及后续执行：存活在宿主环境中的定时器依然是 Render 1 创建的那一个，它在自己的作用域链里寻找到的 count 仍然是最初的 0。它再次调用 setCount(0 + 1)，状态依然被设置为 1。React 发现新旧 state 相同（Object.is 判定），甚至直接跳过组件渲染。数字因此永远定格。

二、深层原因：React 渲染快照与作用域隔离

许多开发者在由 Class 组件向函数组件转变时，会习惯性地将 this.state 的“可变引用”心智模型带到函数组件中。但函数组件的运作方式截然不同：每一次渲染，都是一次拥有独立状态快照的全新函数调用。

如上图所示，当组件渲染时：

• 在 Render 1 中，const count = 0。该次调用中所声明的所有事件处理函数和 Effect，其闭包捕获的都是这个快照版本 0。
• 在 Render 2 中，const count = 1。这是完全不同的另一次函数执行，分配了全新的局部变量与调用栈。
• 如果一个异步回调（无论是 setInterval、setTimeout、addEventListener 还是 Promise 回调）被保存在组件外部且未重新注册，它就只能“凝固”在当初创建它的那次函数作用域中。这就是典型的陈旧闭包（Stale Closure）。

三、怎么解决？三种主流方案与代码实现

针对闭包捕获旧 state 的问题，我们需要根据副作用的具体职责与业务诉求，选用正确的修复方式。

方案一：补齐依赖项数组并提供清理函数

最符合 React 声明式哲学的方式，就是在依赖项数组中如实填写所有被引用的响应式数据（包括 props 和 state）。

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

function CounterWithDeps() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const timer = setInterval(() => {
      console.log('读取最新 count:', count);
      setCount(count + 1);
    }, 1000);

    // 每次 count 发生改变重新执行前，清理上一次的定时器
    return () => clearInterval(timer);
  }, [count]); // 将 count 显式放入依赖项数组中

  return <div>当前计数：{count}</div>;
}

运行机制：当 count 从 0 变为 1 时，React 发现依赖项 [count] 发生变化，会首先执行上一次 Effect 返回的 cleanup 函数（即 clearInterval 清除旧定时器），随后以最新的 count = 1 重新执行 Effect。此时新生成的定时器闭包捕获到的就是当前的 1。

适用场景与代价：这种方案逻辑最直观，非常适合“当某个参数改变时，副作用需要彻底重启”的场景（例如根据不同的 userId 重新发起请求）。但对于高频变化的定时器或持续监听的 WebSocket 连接，每秒钟销毁并重建定时器存在轻微的开销，且如果定时器内含有倒计时重置逻辑，可能会导致计时节奏被打乱。

方案二：使用函数式状态更新（推荐首选）

如果你的副作用中需要读取当前 state 的唯一目的，就是根据旧值计算出新值（例如自增、开关翻转、向数组追加元素），那么函数式状态更新（Functional Updater）是最高效、优雅的解法。

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

function CounterFunctional() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const timer = setInterval(() => {
      // 核心：不再直接读取外层闭包的 count 变量
      // 而是向 setCount 传入一个更新函数，由 React 内部注入最新的状态值 prev
      setCount(prev => prev + 1);
    }, 1000);

    return () => clearInterval(timer);
  }, []); // 依赖项完全无需依赖 count，安全保持为 []

  return <div>当前计数：{count}</div>;
}

运行机制：setCount(prev => prev + 1) 不需要从外部词法作用域中读取 count 变量。它只是向 React 的更新队列中注册了一个计算指令：“请在下一次更新时，取出内部最新的当前值并加 1”。因此，这个回调函数即便始终存活在最初挂载的作用域里，也不会受制于外层闭包快照，彻底解除了对 count 的依赖。

方案三：利用 useRef 保存最新值（跨闭包穿透）

在某些复杂业务场景中，我们既希望定时器或监听器保持长驻（不能因为状态改变而频繁销毁重建），又必须在回调内部读取多个最新状态以执行条件分支或上报日志，而非单纯的调用 setState。此时可以使用 useRef 作为状态的中转容器。

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

function CounterWithRef() {
  const [count, setCount] = useState(0);
  const [step, setStep] = useState(1);

  // 1. 创建一个 ref 容器，其对象引用在组件整个生命周期中保持恒定
  const latestValuesRef = useRef({ count, step });

  // 2. 每次渲染时同步最新值到 ref.current
  latestValuesRef.current = { count, step };

  useEffect(() => {
    const timer = setInterval(() => {
      // 3. 从 ref.current 中解构读取，永远能获取到当前最新的值
      const { count: curCount, step: curStep } = latestValuesRef.current;
      console.log('读取到最新状态组合:', curCount, curStep);

      // 执行复杂逻辑或按指定步长更新
      setCount(prev => prev + curStep);
    }, 1000);

    return () => clearInterval(timer);
  }, []); // 定时器无需重置，依赖保持为 []

  return (
    <div>
      <p>计数：{count}，步长：{step}</p>
      <button onClick={() => setStep(s => s + 1)}>增加步长</button>
    </div>
  );
}

function useLatest(value) {
  const ref = useRef(value);
  ref.current = value;
  return ref;
}

四、选型对比：如何选择最适合的解决方案？

为了在实际开发中快速作出判断，我们可以通过以下对照表和决策树，明确不同方案的权衡边界：

五、工程验证与避坑指南

在日常项目排查与编码规范中，牢记以下三点可以帮助你彻底远离闭包陷阱：

• 验证定时器与状态是否同步：在定时器回调或事件监听中添加 console.log('当前读取值:', val)，观察当界面外部触发更新时，日志中的数值是否能随之连续打印。若连续数秒输出同一个固定值，则必然落入了陈旧闭包。
• 事件监听器的清理：若使用 window.addEventListener，如果依赖项发生变动，一定要确保在清理函数中调用 removeEventListener，避免多个不同时期的闭包回调在全局并存执行，导致内存泄漏与状态串扰。
• React 19 / 未来演进关注：React 官方团队正在推进实验性的 useEffectEvent Hook，其设计目标正是将“响应式依赖”与“非响应式事件逻辑”从语言规范层面进行原生解耦。但在该特性正式普及之前，上述三种方案依然是当前所有生产环境项目中最稳定、最标准的解决路径。