React 16生命周期疑问：为何用getDerivedStateFromProps而非componentDidUpdate？

我完全懂你的困惑！很多刚接触React 16这个新生命周期的开发者都会有这个疑问——毕竟从表面看，componentDidUpdate好像能完成类似的状态更新逻辑。但getDerivedStateFromProps存在的意义，在于它解决了一些componentDidUpdate做不到或者做得不够优雅的场景，咱们慢慢拆解：

核心区别：渲染时机与纯函数约束 #

首先得明确两者最本质的不同：

• getDerivedStateFromProps是静态方法，在组件渲染前触发，它是纯函数——只能接收nextProps和prevState作为参数，返回新的state对象，不能访问this，也不能执行任何副作用操作（比如API请求、DOM操作）。
• componentDidUpdate是组件渲染完成后触发，可以访问this，允许执行副作用，但更新state会触发二次渲染。

为什么需要getDerivedStateFromProps？ #

1. 避免不必要的重复渲染，提升性能 #

拿你给出的代码为例，如果用componentDidUpdate实现相同逻辑：

componentDidUpdate(prevProps) {
  if (prevProps.filtered !== this.props.filtered && this.props.filtered === 'updated') {
    this.setState({ updated: true });
  }
}

这个流程会是：

1. 新props传入 → 组件用旧state（updated: false）渲染一次
2. componentDidUpdate触发 → 更新state为updated: true → 组件再次渲染

而用getDerivedStateFromProps的话，流程是：
新props传入 → 在渲染前计算出updated: true的新state → 组件直接用新state渲染一次

少了一次额外的渲染，在复杂组件或者高频率更新的场景下，这个性能差异会很明显。

2. 强制状态更新逻辑的纯粹性，提升可维护性 #

因为getDerivedStateFromProps是纯函数，你只能基于输入的nextProps和prevState计算新state，不能在里面混入副作用代码。这种约束会让你的状态更新逻辑更清晰、可预测，也更容易编写单元测试。

反观componentDidUpdate，很容易不小心把状态更新和副作用（比如请求数据、操作DOM）混在一起，时间久了组件逻辑会变得臃肿混乱，排查问题也更麻烦。

3. 适配React新特性的兼容性 #

React后续推出的一些特性（比如Suspense）要求组件的渲染过程是可中断、可恢复的。componentDidUpdate是渲染完成后执行的方法，无法适配这种场景；而getDerivedStateFromProps作为渲染前的纯计算逻辑，能更好地和这些新特性配合，保证组件行为的一致性。

回到你的代码：这个方法的作用是什么？ #

你贴的这段getDerivedStateFromProps代码，核心作用就是：在filtered这个props变为'updated'时，同步将组件内部state的updated字段设为true，而且这个状态更新是在组件渲染之前完成的。

这样既避免了二次渲染的性能损耗，又保证了状态更新逻辑的纯粹性——没有任何副作用，只做props到state的映射。

什么时候该用componentDidUpdate？ #

当然不是说getDerivedStateFromProps能完全替代componentDidUpdate，如果你的需求是在props变化时执行副作用（比如根据新props请求后端数据、操作DOM元素），那componentDidUpdate才是正确的选择。只有当你需要纯props到state的同步更新时，getDerivedStateFromProps才是更优解。

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