51工具盒子在使用 React 的类组件时候我们常常会使用 setState 来更新状态，那么 setState 到底是同步的还是异步的呢？
|-----------------|------------------------------------------------------------------------------------------------------------------|
| 1 2 3 4 | changeMessage() { this.setState({message: "你好哇, 安知鱼"}) console.log(this.state.message); // hello world } |
这段代码最终打印结果是 hello world，可见 setState 是异步的操作，我们并不能在执行完 setState 之后立马拿到最新的 state 的结果，那么 setState 一定是异步的吗？
实践 {#实践}
那么 setState 一定是异步的吗？实际上在 React18 之前分为两种情况
- 在组件生命周期或者
React合成事件中，setState 是异步的。 - 在 setTimeout 或者原生 dom 事件中（promise 之类的），setState 是同步的。
React18 之前的同步情况
|---------------------|-----------------------------------------------------------------------------------------------------------------------------------------|
| 1 2 3 4 5 6 | changeMessage() { setTimeout(() => { this.setState({message: "你好哇, 安知鱼"}) console.log(this.state.message); // 你好哇, 安知鱼 }, 0); } |
但是在 React18 之后默认所有的操作都被放到了批处理中（异步处理），即使你像上面那样操作依旧会是异步更新。
如果想要实现同步更新状态并 render 需要使用 flushSync 方法
|-----------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 1 2 3 4 5 6 7 | import { flushSync } from "react-dom"; changeMessage() { flushSync(() => { this.setState({message: "你好哇, 安知鱼"}) }); console.log(this.state.message); // 你好哇, 安知鱼 } |
另外依旧可以传入第二个参数 callback 来获取更新完的状态。
探索 {#探索}
setState 设计为异步其实在 Github 上也有很多相关讨论：RFClarification: why is setState asynchronous?
其中 React 的核心成员(Redux 作者)Dan Abramov 也有对应的回复。
思考 {#思考}
总的看下来以后大概可以总结为以下几点
setState 设计为异步，可以
显著的提升性能
如果每次调用 setState 都进行一次更新，那么意味着 render 函数会被频繁调用，界面重新渲染，这样效率是很低的。
最好的办法应该是获取到多个更新之后进行批量更新。
如果同步更新了 state，但是还没有执行 render 函数，那么
state 和 props 不能保持同步！
state 和 props 不能保持一致性，会在开发中产生很多的问题。所以 React 采用了异步更新，并在 React18 中完全控制。
