我在做React。
TLDR：
但是你可以相信React可以按照要求setState的顺序更新状态吗
- 相同的组件？
是。
- 不同的组件？
是。
该 订单 的更新总是尊重。是否在它们之间看到中间状态取决于您是否在批处理中。
当前（React 16和更早版本）， 默认情况下仅批处理React事件处理程序中的更新
。有一个不稳定的API可以在极少数情况下在需要时强制在事件处理程序之外进行批处理。
在未来的版本中（可能是React
17及更高版本），React默认会批处理所有更新，因此您不必考虑这一点。与往常一样，我们将在React博客和发行说明中宣布有关此更改的信息。
理解这一点的关键是， 无论setState()
您 在React事件处理程序中
执行了多少个组件中的多少次调用，它们都将在事件结束时仅产生一次重新渲染。这对于大型应用程序性能良好至关重要的，因为如果
Child与
Parent每个呼叫
setState()处理click事件的时候，你不想再渲染
Child两次。
在您的两个示例中，
setState()调用都在React事件处理程序中进行。因此，它们总是在事件结束时一起刷新（并且您看不到中间状态）。
更新总是 按照发生的顺序进行浅层合并 。因此，如果第一个更新为
{a: 10}，第二个为{b: 20}，第三个为{a:30}，则呈现状态将为{a: 30, b: 20}。对同一状态键的更新（例如，a在我的示例中）总是“获胜”。
this.state当我们在批处理结束时重新呈现UI时，将更新该对象。因此，如果您需要根据先前的状态（例如增加计数器）来更新状态，则应使用
setState(fn)为您提供先前状态的功能版本，而不是从中读取
this.state。
在您的示例中，我们看不到“中间状态”，因为我们位于启用批处理 的React事件处理程序 中（因为退出事件时React知道）。
但是，在React 16和早期版本中，默认情况下，在React事件处理程序外部都没有批处理。因此，如果在您的示例中，我们使用AJAX响应处理程序代替
handleClick，
setState()则会在发生时立即对其进行处理。在这种情况下，是的，您
会 看到一个中间状态：
promise.then(() => { // We're not in an event handler, so these are flushed separately. this.setState({a: true}); // Re-renders with {a: true, b: false } this.setState({b: true}); // Re-renders with {a: true, b: true } this.props.setParentState(); // Re-renders the parent});我们意识到， 根据您是否在事件处理程序 中 ，行为会有所不同，这很不方便
。这将在以后的React版本中更改，该版本将默认批处理所有更新（并提供选择加入的API以同步刷新更改）。在我们切换默认行为（可能在React 17中）之前，
有一个可用于强制批处理的API ：
promise.then(() => { // Forces batching ReactDOM.unstable_batchedUpdates(() => { this.setState({a: true}); // Doesn't re-render yet this.setState({b: true}); // Doesn't re-render yet this.props.setParentState(); // Doesn't re-render yet }); // When we exit unstable_batchedUpdates, re-renders once});内部所有React事件处理程序都被包装，
unstable_batchedUpdates这就是为什么它们默认情况下被批处理的原因。请注意，将更新打包
unstable_batchedUpdates两次是无效的。当我们退出最外部的
unstable_batchedUpdates调用时，将刷新更新。
该API是“不稳定的”，即默认情况下启用批处理后我们将其删除。但是，我们不会在次要版本中删除它，因此在某些情况下，如果需要在React事件处理程序之外强制进行批处理，则可以放心地依赖它，直到React
17。
总而言之，这是一个令人困惑的话题，因为默认情况下，React仅在事件处理程序中进行批处理。这将在将来的版本中更改，并且行为将变得更加简单。但是解决方案不是
少批处理 ，而是默认情况下 多批处理 。那就是我们要做的。
