每个 React 开发者最终都会遇到同样的难题。你在顶层的 App 组件中获取一个用户对象，然后将其向下传递。一层又一层地传递：经过路由包装器、经过布局外壳、经过侧边栏容器，仅仅是为了让三层深处的一个微小的头像组件能够显示头像。中间的组件根本不需要这个用户对象，它们只是在充当“快递员”。这就是 Prop Drilling（属性钻取），它会让原本整洁的组件树变成一场令人沮丧的“传声筒游戏”。

当数据的结构发生变化时，真正的痛苦才开始。也许后端开始将数据结构从 user.avatar 改为嵌套的 user.profile.avatar。突然之间，你不得不去修改五个从未使用过该数据的 TypeScript 接口或 PropTypes 文件。这正是 React Context API 大显身手的地方。

Context 如何重构数据流

把 Context 想象成放在你家中心的 WiFi 路由器。如果没有它，你需要让以太网线穿过每一个房间，才能让你的笔记本电脑接收到信号。有了它，路由器通过空气进行广播，任何拥有正确密码的设备都可以直接连接。墙壁不再是障碍。

用 React 的术语来说，应用的根节点可以通过组件树广播数据，而无需要求每一层都充当信使。任何嵌套组件都可以订阅该广播，并获取它精确需要的内容。

三个核心组成部分

Context API 可以归纳为三个活动部分。

React.createContext() 用于建立广播频道。它返回一个包含 Provider 和（在旧代码中包含）Consumer 的对象。对于某个特定功能，你只需要调用一次即可。

The Provider 是一个包裹组件树某一部分的组件。它接受一个名为 value 的 prop。你放入该 prop 中的任何内容，对于其所有的后代组件都是可见的，无论它们嵌套得有多深。

useContext 是一个 Hook，它允许函数组件接入该广播。在组件内部，你将创建的 context 对象传递给 useContext，它就会返回当前的值。就这么简单。没有包装器，没有额外的 props。

在 Hooks 出现之前，你必须使用带有 render props 的 Consumer 模式。虽然可行，但它会产生大量的缩进和包装组件带来的混乱。useContext 将这一切简化为函数体内部的一行代码。

什么时候使用 Context 才真正合理

不要出于习惯就去使用 Context。它是为那些被树中不同分支的许多无关组件共享的数据而设计的。优秀的适用场景包括：

  • 主题设置（Theme settings）。 不仅仅是浅色或深色模式，还包括间距令牌（spacing tokens）、调色板和字体比例。手动将这些属性穿透到每一个样式化的按钮和模态框中很快就会让人疲惫不堪。
  • 用户身份验证（User authentication）。 登录状态、权限数组或当前用户对象。你的页眉栏、仪表板小部件和私有路由守卫可能都位于树的不同角落。
  • 语言偏好（Language preferences）。 本地化字符串、日期格式和货币符号。像表单标签这样的深层叶子组件需要这些信息，而不希望路径上的每个父组件都感知到它们。
  • 购物车数据（Shopping cart data）。 商品数量、总金额和添加到购物车的函数。页眉徽标和结账页面需要相同的状态，但它们通常位于完全不同的布局分支下。

一个实用的主题切换器示例

观察 Context 运作最清晰的方式之一就是实现一个主题切换器。以下是如何实现它的步骤，我会跳过那些无关紧要的细节，直击重点。

首先，创建一个 ThemeContext.js 文件。调用 React.createContext() 并存储结果。然后构建一个 ThemeProvider 组件，使用 useState 或 useReducer 来管理当前主题。用你的 context Provider 包裹子组件，并传递一个包含当前主题和切换函数的对象。同时导出 ThemeProvider 和 context 对象本身。

其次，前往应用的入口点。导入 ThemeProvider 并用它包裹你的整个应用程序。如果你跳过这一步，稍后任何尝试读取 context 的操作都只能看到默认值。

第三，在 Header 或 Content 组件内部，导入 context 对象和 useContext。调用该 Hook，解构出主题和切换函数，并根据条件应用你的 CSS 类。添加一个调用切换函数的按钮。该组件永远不会从父组件接收 theme prop，它直接从空气中获取信号。

Prop Drilling, Context, 还是 Redux?

在这些工具之间做出选择，与其说是出于忠诚度，不如说是取决于你状态的形态。

Prop drilling（属性钻取）在两到三层深度的情况下完全没问题。它是显式的，在 IDE 中易于追踪，并且能让依赖关系一目了然。只有当你开始将同一个 prop 穿透六七层时，问题才会显现。

Context API 是 React 自带的。这意味着不会增加额外的 bundle size，也不需要外部配置。它能非常出色地处理中小规模的全局状态，尤其是像主题或用户资料这类变化频率较低的数据。

Redux 需要安装额外的库并编写样板代码（boilerplate）。当你的状态逻辑变得复杂、多个状态切片（slices of state）存在深度交互，或者当你需要时间旅行调试（time-travel debugging）和中间件（middleware）时，它的价值才会体现出来。对于简单的全局数据，使用 Redux 就显得大材小用了。

没人谈论的性能真相

这是区分初级实现与高级实现的关键所在。当 Context Provider 的 value 发生变化时，每一个消费该 context 的组件都会重新渲染。无论该组件关心的特定数据切片是否保持不变，都无济于事。React 会检测到新的引用并调度更新。

如果你将整个应用程序的状态都塞进一个巨大的 StoreContext 中，你实际上就把整个 UI 粘在一起了。更改一个主题设置就会导致你的购物车、仪表盘图表和通知列表全部重新渲染。这是不必要的开销。

按领域（domain）拆分你的 context。为视觉设置保留一个 ThemeContext，为个人资料数据保留一个 UserContext，为交易状态保留一个 CartContext。如果用户修改了显示名称，你的页眉会更新，而不会影响到产品网格。此外，要注意传递给 Provider value 属性的内容。如果你在渲染期间内联传递一个对象字面量 { theme, toggleTheme }，你会在每次渲染时创建一个新的引用，从而触发不必要的更新。如果该值包含函数或非原始数据，请使用 useMemo 来稳定其结构。

浪费数小时的错误

有两个错误会让团队反复踩坑。

忘记导出 context 对象。 很容易只导出 ThemeProvider 组件，然后尝试调用 useContext(ThemeProvider)。事实并非如此。Hook 需要的是 createContext 返回的 context 对象，而不是包装组件。如果你只导出了 Provider，你的消费者将无物可引。

在 Provider 之外调用 useContext。 Hook 会返回你传递给 createContext 的默认值。如果你没有传递默认值，你将得到 undefined。如果你的组件树在 DOM 中将消费者渲染在 Provider 之上，或者 Provider 完全缺失，你的数据将无法送达。请务必检查你的 index 或 root 文件是否确实包裹了整个应用。

核心总结

React Context 并不是一场状态管理革命。它是一个针对特定空间问题的专用工具：在不把每一层都变成“邮局”的情况下，将数据传递给远端的组件。请将其用于真正的全局数据，按领域拆分你的 context 以保护渲染性能，并且在尝试读取信号之前，务必用正确的 Provider 包裹你的组件树。养成这些习惯，你的组件树就能保持整洁、快速且易于理解。