getDerivedStateFromProps可替代componentWillReceiveProps吗？该生命周期除改名外还有何不同？

当然可以替代，而且React官方明确推荐这么做——不过这俩可不只是名字换了，核心设计和使用限制都有不小的区别，我给你拆解清楚：

核心特性差异 #

1. 纯函数约束 vs 自由的副作用操作 #

• componentWillReceiveProps是组件实例方法，你可以在里面干各种事儿：直接修改state、发起API请求、调用实例方法甚至操作DOM。这种高自由度很容易埋下隐患，比如在组件更新前偷偷修改状态，导致渲染逻辑混乱、难以调试。
• getDerivedStateFromProps是静态方法，完全拿不到组件实例的this，只能接收nextProps和prevState两个参数，返回一个用于更新state的对象或者null。它必须是纯函数，不能包含任何副作用——这就从根源上避免了旧生命周期里常见的异步操作、状态突变等问题。

2. 触发时机的范围不同 #

• componentWillReceiveProps只会在父组件传递新的props时触发，组件自身调用setState不会触发这个生命周期。
• getDerivedStateFromProps的触发场景更广泛：父组件传新props、组件自身调用setState、甚至调用forceUpdate时，都会触发它。这意味着你在这个方法里的逻辑要考虑更多场景，不能默认只有props变化才需要更新state。

3. 状态推导逻辑的清晰度 #

• 在componentWillReceiveProps里，你可能会写一堆条件判断，对比新旧props后手动调用this.setState，逻辑分散在方法里，可读性和维护性都差。
• getDerivedStateFromProps要求你把状态推导的逻辑集中在返回值里，一眼就能看出哪些state是从props派生出来的，代码逻辑更清晰，也更容易排查问题。

迁移注意事项 #

如果之前用componentWillReceiveProps只是单纯根据props更新state，那迁移到getDerivedStateFromProps很顺畅；但如果里面包含了副作用（比如API请求、DOM操作），就得把这些逻辑移到componentDidUpdate里处理——毕竟getDerivedStateFromProps只负责状态推导，不允许做其他操作。

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