React 16.3中为何选用getDerivedStateFromProps而非componentDidUpdate？

这个问题问得非常好！很多人刚接触getDerivedStateFromProps的时候都会有这个疑惑——毕竟componentDidUpdate写起来更顺手，逻辑和之前的componentWillReceiveProps也很像。咱们来一步步拆解React推出这个新API的原因，以及它相比componentDidUpdate的核心优势：

• 避免额外的二次渲染
  你给出的componentDidUpdate示例里，当条件满足时调用this.setState，这会触发组件额外的一次渲染流程。虽然React 16.3之后render()的成本确实降低了，但多一次渲染就多一次虚拟DOM的计算和比对，尤其是在复杂组件树或者render包含复杂逻辑的场景下，累积的开销还是不容忽视。
  而getDerivedStateFromProps是在渲染阶段开始前执行的，它返回的新状态会直接合并到当前状态中，之后只需要走一次完整的渲染流程，没有额外的更新步骤，性能更优。

• 纯函数带来的可预测性与可维护性
  getDerivedStateFromProps是一个静态方法，不能访问组件实例的this，这意味着它只能依赖传入的nextProps和prevState来计算新状态，是一个纯函数——给定相同的输入，一定会得到相同的输出，完全没有副作用。
  这种设计让状态更新逻辑变得非常清晰：你不用去担心这个方法里有没有偷偷修改实例的其他属性，或者夹杂了异步操作、DOM操作这类副作用。相比之下，componentDidUpdate里可以做各种操作，时间长了代码很容易变得混乱，状态变化的轨迹也难以追踪，调试和测试都会更麻烦。

• 适配React的未来特性
  React一直在推进并发模式、Suspense这类新特性，而getDerivedStateFromProps正是为这些特性量身设计的。在并发模式下，React可能会中断、暂停甚至重启渲染过程，像componentDidUpdate这种在渲染完成后执行的生命周期，可能会因为渲染被中断而出现多次执行、状态不一致的问题。
  但getDerivedStateFromProps作为纯函数，没有任何副作用，不管渲染被中断多少次，只要输入的props和state不变，输出的新状态就不变，完全适配并发模式的需求，能保证组件行为的一致性。

• 消除竞态条件
  在componentDidUpdate里调用setState是异步的，如果此时有新的props传入，可能会出现状态更新和props变化不同步的竞态问题。而getDerivedStateFromProps每次都会在渲染前根据最新的props和state计算状态，确保状态始终与props保持同步，从根源上避免了这类问题。

举个实际场景：如果你的组件需要根据props的变化立即更新状态，用getDerivedStateFromProps能确保状态更新和渲染是同步的，而componentDidUpdate的异步更新可能会导致界面出现短暂的不一致。

总的来说，虽然componentDidUpdate在简单场景下能工作，但getDerivedStateFromProps在性能、可维护性和未来兼容性上都更胜一筹，这也是React官方推荐它作为props驱动状态更新的首选方式的原因。

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