在React开发中，状态管理是核心环节，但不少开发者都曾遭遇一个令人困惑的现象：异步操作完成后，明明已经通过setState更新了状态，控制台打印也确认新值正确，可UI却顽固地显示着旧值。这种现象在数据请求、定时器、事件处理等场景中反复出现，甚至让部分开发者怀疑React的渲染机制出现了Bug。实际上，这并非React的缺陷，而是对状态更新机制理解不足导致的常见误区。

问题重现：一个典型的异步场景

假设我们有一个简单的计数器组件，用户点击按钮后，会模拟一个异步操作（如API请求），然后更新计数器状态：

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

  const handleClick = () => {
    setCount(count + 1); // 同步更新
    setTimeout(() => {
      console.log('当前count:', count); // 打印旧值
      setCount(count + 1); // 此时更新的是旧值+1
    }, 1000);
  };

  return <div onClick={handleClick}>{count}</div>;
}

点击一次按钮后，UI从0变为1，但1秒后却跳回1（实际应变为2）。控制台打印的count值依然是0——异步回调中捕获的是闭包中的旧状态，导致第二次更新基于过期数据，最终UI显示异常。

根源剖析：闭包陷阱与异步调度

React状态更新的核心机制包括两个关键点：

1. 闭包捕获旧值
当组件渲染时，每次render都会生成一个独立的函数作用域。异步回调（如setTimeout、Promise.then、useEffect的清理函数）中引用的状态变量，实际是本次渲染时闭包内的快照，而非最新的实时值。上例中，setTimeout回调捕获的是第一次渲染时的count（0），即使1秒后状态已更新，回调内依然使用旧值。

2. 状态更新的批处理
React 18之前，setState在同步代码中是同步执行的，但在异步回调中却是批处理且异步更新的。开发者调用setState后，新状态并不会立即生效，而是进入更新队列，等待下一次渲染。这意味着在同一个异步操作中连续调用setState，可能因为闭包问题导致多个更新相互覆盖。

解决方案：三种有效应对策略

1. 函数式更新（推荐）

使用setState的函数形式，确保始终基于最新状态更新：

setTimeout(() => {
  setCount(prev => prev + 1);
}, 1000);

这样，React会在渲染时传入最新状态，彻底规避闭包陷阱。

2. useRef保存最新值

useRef是一个不引起重新渲染的容器，可存储最新状态：

const countRef = useRef(count);
useEffect(() => {
  countRef.current = count;
}, [count]);

// 异步回调中
setTimeout(() => {
  setCount(countRef.current + 1);
}, 1000);

适合需要多次读取最新值的场景，但要注意手动同步。

3. 使用useCallback配合依赖数组

对于事件处理函数，确保回调内部引用的状态是最新的：

const handleClick = useCallback(() => {
  // 这里没有闭包问题，但依然推荐函数式更新
}, [count]);

不过，更优解还是直接使用函数式更新。

进阶思考：为什么React不自动修复？

部分开发者认为React可以在异步回调中自动“感知”状态变化，但这是违背JavaScript闭包本质的。React无法追踪每个异步任务内部的变量引用，且函数式更新提供了显式、可靠的解决方案。此外，React 18的自动批处理机制优化了同步和异步场景的状态合并，但闭包问题仍需开发者自己注意。

实战建议：养成两个习惯

  1. 所有异步状态更新都使用函数式形式：无论setState还是useReducer的dispatch，都优先传递函数而非值。
  2. 使用ESLint插件：安装eslint-plugin-react-hooks，它能检测出缺失依赖项和潜在闭包问题，并提供修复建议。

结语

“状态更新但UI不更新”是新手通往高手之路的必修课。理解闭包与React调度机制后，这个问题就不再神秘。下次遇到类似情况，不妨先检查异步回调中是否使用了旧状态快照，并迅速采用函数式更新方案。记住：React始终可靠，只是需要你懂得如何与它的运行规律共舞。