关于getDerivedStateFromProps替代componentWillReceiveProps的技术疑问

一、componentWillReceiveProps被废弃的核心原因 #

• 它是同步生命周期钩子，但很多开发者会在里面写异步逻辑（比如API请求）。不是说它会阻塞渲染，而是异步操作完成后调用setState，很容易触发不必要的重复渲染，甚至出现竞态问题——比如两个API请求先后返回，导致组件状态被旧数据覆盖，出现和当前props不匹配的情况。
• 另外，这个钩子允许直接修改this.state或者执行各种副作用操作，完全违背了React单向数据流的设计原则，导致组件状态依赖混乱，bug很难追踪。
• 同步特性本身不是问题，但它的灵活性导致了大量不可预测的组件行为，React团队为了引导开发者写出更稳定、可维护的组件，最终选择废弃它。

二、getDerivedStateFromProps的设计初衷与限制 #

它是静态钩子，执行时机不阻塞渲染流程（所谓的“异步”指的是这个意思），核心职责就是纯根据props的变化计算并返回新的state：

• 静态特性意味着它没有组件实例的this，没法访问组件内部的状态或方法，这是故意设计的——就是为了强制开发者在这里写纯逻辑，杜绝副作用。
• 为什么不能做API调用？因为API请求属于副作用操作，而这个钩子的定位是“纯计算状态”，如果在这里加异步请求，会让组件渲染流程混入不可控的副作用，同样会引发竞态问题，违背了它的设计目的。这类操作应该放在componentDidUpdate（类组件）或者useEffect（函数组件）里。
• 为什么不能用setState？因为它的返回值就是要更新的state，React会自动把返回的对象合并到组件状态中，根本不需要手动调用setState。而且它是静态方法，连this都访问不到，自然也没法调用this.setState。

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