Redux与Context API的差异及相关技术疑问

1. Context API任意状态值变更是否会导致所有绑定组件重渲染？ #

是的，默认情况下，当Context的value引用发生变化时，所有通过useContext或Context.Consumer订阅该Context的组件都会触发重渲染——哪怕组件只用到了Context中未变化的属性。React判断Context更新的核心依据是value的引用是否改变，只要整个value对象的引用变了，无论内部属性是否更新，订阅组件都会重新渲染。

2. Redux及Redux Toolkit是否底层使用Context API？ #

是的，React-Redux（连接React与Redux的官方绑定库）从v7版本开始，底层依赖React Context API来传递Redux store实例。Redux Toolkit是Redux的官方工具集，它仅简化了Redux的配置、slice编写等流程，最终仍通过React-Redux与React集成，因此Redux Toolkit同样依赖Context API的底层实现。

3. Context API是否比Redux更早出现但未暴露给开发者？ #

并非如此。Redux在2015年就已发布，而React正式推出稳定版Context API（即createContext、useContext这套API）是在2018年的React 16.3版本。在此之前，React内部确实存在早期的Context机制，但未对外开放，当时Redux是通过自身实现的订阅发布逻辑（比如connect高阶组件直接订阅store变化）来更新组件。直到稳定版Context API推出后，React-Redux才改用它来传递store。

4. Redux底层用Context API却能避免全组件重渲染的实现细节？ #

React-Redux主要通过以下机制避免不必要的重渲染：

• 精准状态选择与浅比较：
  使用useSelector钩子时，开发者可以指定组件仅订阅所需的状态片段。React-Redux会自动对当前选择的结果与上一次结果做浅比较（默认用===判断，也支持自定义比较函数），只有当结果确实变化时，才会触发组件重渲染。即使整个store状态更新，只要组件依赖的部分未变，就不会触发重渲染。
• 拆分的Context层级：
  React-Redux内部并未将整个store状态放入单个Context，而是拆分了多个独立Context：例如一个用于传递store实例，一个用于处理订阅逻辑。只有当store实例发生变更（几乎不会出现）时，才会触发全组件重渲染；状态更新时，仅订阅对应状态的组件会收到通知。
• 记忆化处理（针对旧版connect）：
  旧版connect高阶组件通过mapStateToProps选择状态后，会对返回的props做记忆化处理（如用shallowEqual比较），只有当props真正变化时，才会更新包裹的组件。

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