React修改state值时为何使用callback function而非直接用state

核心原因本质是两点：React状态更新的异步批处理机制，以及JS函数的闭包特性，直接引用作用域内的state很容易拿到过期的旧值，导致更新不符合预期。

1. 直接引用作用域state会触发闭包旧值问题 #

React每次组件渲染都会生成独立的闭包快照，当前作用域里拿到的state、props都是本次渲染瞬间的固定值，不会跟着后续状态更新变化。
不管你在事件回调、useEffect、异步定时器、接口请求回调里拿到的state，都只是绑定那次渲染的快照，不是实时最新值。

举个最常见的异步场景bug：

const [count, setCount] = useState(0)

useEffect(() => {
  // 组件挂载时注册3秒后执行的回调
  setTimeout(() => {
    // 这里的count永远是首次渲染时的0，哪怕3秒内你已经把count点到了10
    console.log(count) // 永远输出0
    setCount(count + 1) // 永远会把count设为1，覆盖掉之前的所有更新
  }, 3000)
}, [])

2. React的批处理机制会让同步连续更新失效 #

React默认会把同一个事件循环里的所有state更新做批处理合并，不会每改一次就立刻重渲染拿最新值。如果你连续多次更新state、且新值依赖旧值，直接引用当前作用域的state会导致所有更新都用同一个旧值计算，结果完全不符合预期。
最典型的连续加3的反例：

const handleClick = () => {
  // 三次更新都在同一个同步执行上下文里，React会批处理
  // 这三行里拿到的count都是点击瞬间渲染快照里的值，比如初始是0
  setCount(count + 1) // 计算新值：0+1=1
  setCount(count + 1) // 还是拿0计算：0+1=1
  setCount(count + 1) // 还是拿0计算：0+1=1
  // 最终三次更新合并后count只会变成1，根本达不到加3的预期
}

3. 回调式更新能保证拿到的永远是最新的前序状态 #

当你给状态更新函数传入回调时，React会在真正执行更新的时机，把上一次更新完成后的最新状态值作为参数传给你的回调，完全不受闭包快照、批处理合并的影响。
上面两个bug场景换成回调写法就能完全解决：

// 连续加3的正确写法
const handleClick = () => {
  setCount(prev => prev + 1) // prev是0，计算得1
  setCount(prev => prev + 1) // prev拿到上一步算完的1，计算得2
  setCount(prev => prev + 1) // prev拿到上一步算完的2，计算得3
  // 最终count正确变成3
}

// 异步定时器的正确写法
setTimeout(() => {
  setCount(prev => prev + 1) // 不管定时器等多久，prev永远是触发更新那一刻的最新值
}, 3000)

注意：不是所有状态更新都必须用回调。如果你的新状态和旧状态完全无关，比如直接把弹窗状态设为true、把用户信息直接替换成接口返回的全新对象，这种场景直接传值完全没问题，不会产生bug。只有当新状态的计算依赖旧状态的值时，才必须用回调式更新保证结果正确。

内容的提问来源于stack exchange，提问作者Arabboy Ismoilov