Redux 内部实现是否使用了 Context API？

答案是分场景的：纯 Redux 核心库（redux npm 包）是框架无关的通用状态管理工具，本身没有依赖 React 的 Context API；但 React 生态中配合 Redux 使用的官方绑定库 React-Redux，内部确实基于 Context API 实现了核心的 Store 传递能力，这也是该面试题的核心考察点。

1. 专属 Context 实例创建 #

React-Redux 内部会初始化一个私有的、不对外默认导出的 Context 对象，默认值为 null，专门用来传递 Redux 的 Store 实例，不会和业务代码中自行创建的 Context 产生冲突。

补充版本差异：React-Redux v6 之前使用的是 React 旧版的 legacy context 实现，v6 及之后全面切换为 React 16.3 推出的正式版 Context API，v7 版本又在 Context 传递的基础上新增了单独订阅的性能优化逻辑，解决了 Context 全量更新的性能问题。

2. Provider 组件的注入逻辑 #

我们在项目根节点包裹的 <Provider> 组件，本质就是上述私有 Context 的 Provider 封装。它接收开发者传入的 Store 实例作为 value 值，把 Store 放到 Context 中向下传递给所有子孙组件，对应业务代码的常规写法如下：

import { Provider } from 'react-redux'
import store from './store'
import App from './App'

// 根节点注入 Store
const root = ReactDOM.createRoot(document.getElementById('root'))
root.render(
  <Provider store={store}>
    <App />
  </Provider>
)

3. 组件侧的 Store 消费逻辑 #

不管是类组件使用的 connect 高阶函数，还是函数组件使用的 useSelector/useDispatch Hook，内部第一步都会调用 React 原生的 useContext 方法，从上述私有 Context 中获取 Provider 注入的 Store 实例。如果组件不在 Provider 的包裹范围内，就会抛出「找不到 Redux Store」的常见错误。

4. 性能优化逻辑 #

Context API 本身存在一个特性：只要 Provider 的 value 发生变化，所有消费该 Context 的组件都会强制重渲染。React-Redux 巧妙规避了这个缺陷：

• Context 中传递的 Store 实例本身从初始化后就永远不会变更，不会触发 Context 层面的全量重渲染
• 每个使用 connect 或 useSelector 的组件会单独订阅 Store 的状态变化，只对比自己依赖的状态片段是否发生变更，再决定是否触发自身重渲染，性能损耗极低。

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