通过一系列无关组件传递 props 是一项繁琐的工作。今天你还在交付功能，明天可能就为了重命名一个 prop 而要修改六个文件。这就是所谓的“属性钻取”（prop drilling）的本质：父组件拥有数据，深层的子组件需要它，而它们之间的每个组件都成了“快递员”。应用虽然还能运行，但代码库变得非常脆弱。移除中间层，半个组件树就会崩溃；修改一个类型，TypeScript 就会在三个目录中报错。React Context API 的存在，就是为了彻底消除这些中间人。

属性钻取究竟是什么样子的

想象一个标准的 App 外壳。你有一个 App 组件负责获取当前用户。在 App 内部是 Layout，Layout 内部是 Sidebar，Sidebar 嵌套了 Navigation，最后在 Navigation 内部，你找到了真正需要用户对象的 UserAvatar。

你的代码最终会变成这样：

function App() {
  const user = { name: 'Aarav', role: 'admin' };
  return <Layout user={user} />;
}

function Layout({ user }) {
  return <Sidebar user={user} />;
}

function Sidebar({ user }) {
  return <Navigation user={user} />;
}

function Navigation({ user }) {
  return <UserAvatar user={user} />;
}

Layout、Sidebar 和 Navigation 除了向下传递用户对象外，什么也没做。它们积累了并不属于自己的 props，接口变得臃肿，测试它们时还需要模拟（mock）它们从未触碰过的数据。真正的罪魁祸首是这种模式蔓延的速度。添加一个 isLoggedIn 标志、一个 locale 字符串或一个 theme 值，同样的戏码就会重演。

Context API 如何改变游戏规则

把 Context API 想象成一个 WiFi 路由器。与其为了连接每个设备而把长电缆拉遍每个房间，路由器通过空气发送信号。范围内任何设备都可以直接连接。用 React 的术语来说，路由器是 Provider，信号是你的状态或数据，而设备是任何调用了 useContext 的嵌套组件。

设置包含三个部分：

  • React.createContext() 构建数据通道。
  • Provider 包裹树的一部分并传输一个值。
  • useContext hook 让后代组件无需触碰中间 props 即可接收该值。

你仍然拥有一个组件树，但根节点与叶子节点之间的分支不再需要达成“快递协议”了。

从零开始构建 Context

让我们用主题设置（theme settings）做一个具体的例子，因为大多数应用在某个时刻都需要浅色或深色模式。

首先，创建 context 对象。这就是管道：

import { createContext, useState, useMemo } from 'react';

const ThemeContext = createContext(null);

export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');

  return (
    <ThemeContext.Provider value={{ theme, setTheme }}>
      {children}
    </ThemeContext.Provider>
  );
}

export default ThemeContext;

然后用 Provider 包裹你的应用。通常这发生在根节点附近：

import { ThemeProvider } from './ThemeContext';

function App() {
  return (
    <ThemeProvider>
      <Layout />
    </ThemeProvider>
  );
}

现在任何后代组件都可以直接获取信号。这是一个埋在 UI 深处的切换按钮：

import { useContext } from 'react';
import ThemeContext from './ThemeContext';

function ThemeToggle() {
  const { theme, setTheme } = useContext(ThemeContext);

  return (
    <button
      onClick={() => setTheme(prev => prev === 'light' ? 'dark' : 'light')}
    >
      Current theme: {theme}
    </button>
  );
}

注意到 Layout、Sidebar 和 Navigation 从未见过 theme prop。它们正常渲染，而 ThemeToggle 直接从 context 中获取它所需的内容。这种连接在外部是不可见的，而这正是其核心所在。

Context 到底适用于哪些场景

Context 最适合处理那些许多远端组件共享、但没有任何单一父组件能清晰拥有的数据。优秀的候选对象包括：

  • 主题设置，如浅色或深色模式、强调色或字体缩放。
  • 身份验证状态，如当前用户对象、登录状态或会话过期。
  • 语言和区域设置，用于国际化。
  • 购物车数据，必须在页眉徽标、迷你购物车下拉菜单和结账页面之间保持同步。

抵制将所有局部状态都塞进 Context 的冲动。向下两层的表单输入不需要进行全局广播。将 Context 留给真正的横切关注点（cross-cutting concerns），其余的请保持为普通的 props。

性能陷阱及如何规避

Context 并非免费的午餐。当 context 值更新时，所有挂载到该 context 的组件都会重新渲染，即使它们关心的那部分值并没有改变。一个经典的错误是在每次父组件渲染时，都向 Provider 传入一个新的对象字面量。

在我们的主题示例中，每当 ThemeProvider 因为其父组件更新而重新渲染时，表达式 { theme, setTheme } 都会创建一个全新的对象。React 会识别到一个新的引用，从而导致所有消费者（consumers）都进行更新。如果你的主题很少改变，但应用状态经常改变，你就在为不必要的渲染买单。

解决方法有两个方面。

按更新频率拆分你的 Context。 一个每登录一次才改变一次的 UserContext 不应该与每隔几秒更新一次的 NotificationContext 共享同一个 Provider。将它们分开，这样静态数据就不会随着易变数据一起“搭乘”重新渲染的列车。

当值是对象或数组时，使用 useMemo 包裹该值。 给 React 一个稳定的引用：

export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');

  const value = useMemo(() => ({ theme, setTheme }), [theme]);

  return (
    <ThemeContext.Provider value={value}>
      {children}
    </ThemeContext.Provider>
  );
}

现在，只有当 theme 发生实际变化时，对象标识（object identity）才会发生变化。那些关注该上下文但被下游的 React.memo 保护着的后代组件将会跳过不必要的渲染工作。

浪费时间的错误

生产代码中仍然会出现的两个错误很容易预防。

首先，忘记导出 context 本身。如果你只导出 Provider 包装器并将 context 对象私有化，那么开发新功能的开发者在不重构你的模块的情况下，将无法调用 useContext。请导出 context，以便使用者可以清晰地同时导入 provider 和 consumer hook。

其次，在相应的 Provider 之外调用 useContext。如果 ThemeToggle 在未被 ThemeProvider 包裹的树分支中渲染，该 hook 将返回传递给 createContext 的默认值；如果你没有传递任何值，则返回 undefined。这会导致诸如 cannot read property of undefined 之类的静默失败。你可以通过分配一个合理的默认值，或者在 hook 调用早期抛出一个清晰的错误来防止这种情况。

Context vs Redux：保持简单

你并不总是需要 Redux。对于中等规模的项目，Context 配合 useState 或 useReducer 就能覆盖大部分状态共享需求。当你需要时间旅行调试（time-travel debugging）、复杂的中间件或必须按顺序回滚的全局事务时，Redux 的优势才会体现出来。如果你的整个状态逻辑只是一个用户对象、一个主题字符串和一个购物车数组，那么引入一个 store 库只会增加你永远用不到的样板代码。

话虽如此，Context 本身并不是一个完整的状态管理系统。它不会为你提供单一的全局快照，也不会跨不相关的 context 进行批量更新。请将其作为 prop drilling 的替代方案，而不是将其作为整个数据层的操作系统。

核心总结

不要再把 props 穿透传递给那些并不关心的组件了。为那些真正跨越组件树的数据创建专注的 context，将 provider 包裹在足够高的层级以覆盖消费者，并且在传递集合或函数时始终保持 value 对象的稳定性。Context API 让你的 React 代码保持直接：props 保持局部性，全局数据“无线”传输，而你的组件边界则保持整洁。