React同一事件回调内setState更新state后立即访问该值的假设是否正确

你的假设完全正确。

React类组件中，在合成事件、生命周期方法这类由React统一管控的执行上下文里，setState是异步批量更新的：

• 调用setState后，React不会即刻修改this.state指向的原有状态对象
• 所有触发的状态更新会被暂存到更新队列，等当前整段同步代码执行完毕后，React才会统一合并状态、触发重渲染，最后把最新状态值挂载到this.state上

对应你这段代码的实际执行路径：
当isRecipientSelected初始值为false时，运行流程是：

1. 进入第一个if分支，调用setState标记要将isRecipientSelected改为true
2. 紧接着执行第二个if的条件判断时，读取的this.state.isRecipientSelected依然是旧的false值
3. 哪怕你的代码意图是“只要选中了收件人就执行后续匹配逻辑”，第二个if的条件也会因为读到的状态值为假而无法命中，最终出现和预期不一致的逻辑bug

• 不依赖setState之后读取this.state拿新值，在同步执行阶段直接提前计算出要判断的最终状态值，不需要等React的状态更新流程走完
  示例参考：

  onContactChange = (contactInfo) => {
    // 提前算出更新后的isRecipientSelected值
    const nextSelectedStatus = this.state.isRecipientSelected ? this.state.isRecipientSelected : true
    if (!this.state.isRecipientSelected) {
      // setState本身是合并更新，不需要展开整个this.state
      this.setState({ isRecipientSelected: true });
    }
    // 用提前计算好的值判断，不直接读this.state
    if (contactInfo.selectedContactAccount.type && nextSelectedStatus) {
      // 后续业务逻辑
    }
  }
  

• 如果你确实需要等状态完全更新完成后再执行后续判断，可以把逻辑放到setState的回调函数中——这个回调接收的参数就是更新后的最新状态，会在React完成状态合并、重渲染之后执行。

不要把不同执行上下文的setState行为混为一谈：在原生DOM事件回调、setTimeout、Promise异步回调这类不受React批处理规则管控的场景里，setState是同步立刻更新this.state的。但你写的onContactChange是React体系下绑定的合成事件回调，完全处于React批处理的覆盖范围内，调用完setState立刻读this.state，拿到的一定是旧值。

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