React中何时可以安全直接依赖this.state的取值？

首先明确：setState异步更新会导致问题的核心前提，是你读取this.state的时机和状态最终计算提交的时机之间，存在其他会修改同一状态的逻辑，导致你拿到过期旧值，不是说只要读了this.state就一定会出错。

你看到的官方井字棋教程里的写法完全可以正常运行，原因非常直接：

• 这个handleClick是绑定在格子上的点击回调，只有用户真实点击的时候才会触发，整个函数是同步执行完的。从函数开始执行到调用setState的整个过程中，没有任何其他代码会修改squares或者xIsNext这两个状态，你读到的this.state就是当前页面已经渲染完成、完全稳定的最新状态，不存在过期问题。
• 这类用户点击、输入的离散交互场景下，React会等整个事件回调里的所有同步代码执行完，才会统一进入批处理更新流程。两次点击之间React一定已经完成了上一轮的状态更新和重渲染，根本不会出现同一次更新流程里多次读取旧值、状态互相覆盖的问题。

可以安全直接读取this.state的场景 #

只要同时满足以下条件，直接给setState传对象、依赖当前this.state取值完全不会出问题：

• 读取state的逻辑运行在已经完成渲染的稳定交互回调中，比如原生DOM点击、表单输入这类用户触发的同步事件回调，回调执行过程中没有其他并发触发的状态更新
• 同一个回调里只会调用一次setState，不存在连续多次更新同一状态的逻辑
• 状态更新不涉及和其他组件、外部逻辑的联动，不存在更新被延迟、打断的可能

比如点击按钮打印当前存在state里的表单值、单次点击切换弹窗显示/隐藏（没有连续多次触发更新的逻辑），这类场景直接读this.state写起来更直观，也不会有bug。

必须使用函数式setState的场景 #

只要满足任意一条，就必须用setState(prevState => 计算返回新状态)的写法，不能直接依赖this.state的取值：

• 新状态的计算完全依赖上一次的状态结果，比如计数器增减、给状态数组追加/修改项、翻转布尔标记这类逻辑——尤其是同一回调里可能多次触发这类更新的时候，直接读this.state会导致多次更新读到同一个旧值，最终结果不符合预期。比如点击一次按钮要给计数器加3，直接读this.state.count写的话三次更新都会拿到同一个初始值，最终只会加1，用函数式写法就能每次拿到上一次更新后的最新值做计算。
• 更新逻辑写在异步回调里，比如接口请求返回回调、定时器、Promise.then这类场景，这时候回调里捕获的this.state很可能是闭包留存的旧值，不是触发更新时的最新状态。
• 你在写可复用的通用组件、自定义Hook，没法保证外部调用时会不会在同一次更新流程里触发多次状态修改，用函数式写法是最稳妥的兼容方案。

教程里的写法本质是入门阶段为了降低理解成本写的直观实现，本身在那个特定场景下没有逻辑问题，如果要写最严谨的、兼容所有React版本和更新场景的写法，改成函数式形式即可：

handleClick(i) {
  this.setState(prevState => {
    const squares = prevState.squares.slice();
    squares[i] = prevState.xIsNext ? 'X' : 'O';
    return {
      squares: squares,
      xIsNext: !prevState.xIsNext
    };
  });
}

补充：React 18 之后所有场景下的更新默认都会走自动批处理，只要更新逻辑依赖前序状态，优先用函数式setState是零成本的稳妥选择，不用额外判断场景。

内容的提问来源于stack exchange，提问作者i'mlearningtocode