setState()没有立即生效这个问题，在做项目的时候不止一次遇到。每次遇到的时候，解决办法都是现成的，并没有细细的深入探究为什么在调用setState的时候this.state在一定几率下没有立即生效的原因。这次在做****的时候，又遇到了这个问题，决定详细探究一下，查一查资料，并做一个记录。
首先，看一下react官方对setState这个API的定义。在react的官方文档里这样描述setState()这个API:
setState(object nextState[, function callback])
合并 nextState 和当前 state。这是在事件处理函数中和请求回调函数中触发 UI 更新的主要方法。另外，也支持可选的回调函数，该函数在 setState 执行完毕并且组件重新渲染完成之后调用。
同时还提出了注意点：
setState()不会立刻改变 this.state，而是创建一个即将处理的 state 事务。在调用该方法之后获取 this.state 的值可能会得到现有的值，而不是最新设置的值。不保证 setState() 调用的同步性，为了提升性能，可能会批量执行 state 转变和 DOM 渲染。
所以，一般情况下，我们想要确保在state合并完成之后执行方法，就会把需要执行的内容写在回调函数内。
当然，不管怎样还是要代码说话,
class Example extends React.Component {
constructor(){
super();
this.state = {
val:0
};
}
componentDidMount() {
this.setState({val:this.state.val+1});
console.log(this.state.val);//第1次 0
this.setState({val:this.state.val+1});
console.log(this.state.val);//第2次 0
setTimeout(() => {
this.setState({val:this.state.val+1});
console.log(this.state.val);//第3次 2
this.setState({val:this.state.val+1});
console.log(this.state.val);//第4次 3
},0)
}
}
这四次输出的val分别是0，0，2，3，是不是有点出乎意料。在第一次和第二次输出的时候setState()到底干啥去了。
众所周知，react的源码的体量还是有点儿大的。但是为什么react的执行会如此迅速。根据核心开发者之一 Pete Hunt的阐述，其中有一个原因就是每一个组件都有其完整的生命周期，这些生命周期方法保证所有对 DOM 的修改都是批量更新的（batch update）。
为了搞明白setState之后发生了什么。我大致梳理了一下源码(我看的源码版本是0.14.7),将代码的重点整理如下图：
首先，在我们调用 setState 方法后，要明确的一点是 state 是不一定会立即更新的。因为此时会调用一个 enqueueSetState 方法，传入要更新的 state 。如果存在 callback 的话，也会调用 enqueueCallback 的方法。 在 enqueueSetState 方法中，会将新的 state 暂时存入一个临时数组 _pendingStateQueue 中。然后再调用 enqueueUpdate 方法。在 enqueueUpdate 方法中就出现了传说中的batchingStrategy 批处理策略。 在这里用 isBatchingUpdates 这个标志来标记是否处于一次 batchupdates 中，如果不处于一次 batchupdates，那么就会执行 update，否则，就会将当前 component 存入 dirtyComponents 数组中。
根据以上的分析，就能知道，为什么在一次 setState 执行的时候，state 没有立即更新。
同样的，为什么最上面示例代码的执行结果是0，0，2，3，是因为两次直接执行的 setState 和在 setTimeout 中的 setState 的调用栈不一样。直接执行 setState 的时候，此时正处于一次 batchupdates，所以并不会立即更新，而是暂存，等同一批的 state 都合并之后，再一次性更新。
