第 11 章

Context 的边界：什么问题它解决不了

第11章：Context 的边界：什么问题它解决不了

Context 是一把精良的手术刀，但你不能用它来盖房子。理解它的边界，是选择正确状态管理工具的第一步。

本章核心问题：Context 适合什么场景？什么时候你已经超出了它的边界？ 读完本章你将理解：

Context 为低频变化的全局数据而设计，高频更新场景应使用外部状态库
组件组合（children/slots 模式）往往比 Context 更好地解决 prop drilling
当你开始拆分 Context 来优化性能时，说明需要更专业的状态管理工具

Level 1 · 你需要知道的（1-3年经验）

为什么 Context 不适合高频状态

问题的根源在于 React 的 Context 实现机制。当你调用 useContext(MyContext) 时，React 会把当前组件注册为这个 Context 的消费者（consumer）。一旦 Context 的 value 引用发生变化，React 会遍历整棵消费者树，标记所有消费者为"需要重新渲染"。

这是 O(n) 复杂度的操作，n 是消费者数量。

// 反模式：用 Context 管理高频变化的状态
const MouseContext = createContext({ x: 0, y: 0 });

function MouseProvider({ children }: { children: React.ReactNode }) {
  const [pos, setPos] = useState({ x: 0, y: 0 });

  useEffect(() => {
    const handler = (e: MouseEvent) => {
      setPos({ x: e.clientX, y: e.clientY }); // 每次鼠标移动触发
    };
    window.addEventListener('mousemove', handler);
    return () => window.removeEventListener('mousemove', handler);
  }, []);

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

// 问题：即使 DeepChild 只需要 pos.x，pos.y 变化时它也会重渲染
// 即使 Header 完全不用鼠标坐标，只要它调用了 useContext(MouseContext) 就会重渲染
function Header() {
  const _pos = useContext(MouseContext); // 为什么要用这个？
  return <header>...</header>;
}

用基准测试量化差距

下面的基准模拟了一个拥有 50 个消费者组件的场景，测量每秒状态更新的渲染耗时：

// 测试场景：50 个子组件订阅同一个计数器状态
// 方案 A：Context
const CountContext = createContext(0);

function ContextCounter() {
  const count = useContext(CountContext);
  return <div>{count}</div>;
}

// 每次 setCount，所有 50 个 ContextCounter 都会重新渲染
// Chrome DevTools Profiler 结果：~12ms per update（50个组件）

// 方案 B：Zustand
const useCountStore = create<{ count: number }>()(set => ({
  count: 0,
  increment: () => set(state => ({ count: state.count + 1 })),
}));

function ZustandCounter() {
  const count = useCountStore(state => state.count);
  return <div>{count}</div>;
}

// 每次 increment，只有 count 实际变化时对应组件才重渲染
// Chrome DevTools Profiler 结果：~2ms per update（精准订阅）

差距来源很清晰：Context 使用 React 的协调器（Reconciler）广播更新，而 Zustand 使用 useSyncExternalStore 在 React 渲染循环之外管理状态，只通知真正关心的订阅者。

"属性钻透不总是坏事"

软件社区有一个误解：prop drilling（属性钻透）是需要被消灭的反模式。这个观点值得挑战。

Prop drilling 的核心优势是显式依赖。当你看到一个组件接收 userId prop 时，你立刻知道这个组件依赖用户 ID，你可以追踪数据流，你可以在测试中注入不同的值。Context 切断了这条可追踪链，代价是隐式依赖——组件从"空气"中取值，数据流变得不透明。

// Prop drilling：显式、可追踪、易测试
function UserDashboard({ userId }: { userId: string }) {
  return <UserProfile userId={userId} />;
}

function UserProfile({ userId }: { userId: string }) {
  return <UserAvatar userId={userId} />;
}

function UserAvatar({ userId }: { userId: string }) {
  const { data } = useUser(userId); // 实际的数据获取
  return <img src={data?.avatar} />;
}

// 测试极简单
render(<UserAvatar userId="test-123" />);

当 prop drilling 真正成为问题时（超过 3-4 层、多个不相关数据同时穿透），正确的答案往往不是 Context，而是组件组合。

Level 2 · 它是怎么运行的（3-5年经验）

组件组合：比 Context 更好的答案

React 的组合模型允许你把组件作为 props 传递，这比 Context 更强大，且保持显式依赖：

// 问题场景：Avatar 需要 user，Button 需要 onAction，嵌套 3 层
// 传统 prop drilling（痛苦）
function Page({ user, onAction }: PageProps) {
  return <Layout user={user} onAction={onAction} />;
}
function Layout({ user, onAction }: LayoutProps) {
  return <Sidebar user={user} onAction={onAction} />;
}
function Sidebar({ user, onAction }: SidebarProps) {
  return (
    <>
      <Avatar user={user} />
      <ActionButton onAction={onAction} />
    </>
  );
}

// 解决方案：组件组合，把"已经组装好的节点"传下去
function Page({ user, onAction }: PageProps) {
  // 在顶层组装好，往下传 ReactNode 而不是数据
  return (
    <Layout
      sidebar={
        <>
          <Avatar user={user} />
          <ActionButton onAction={onAction} />
        </>
      }
    />
  );
}

function Layout({ sidebar }: { sidebar: React.ReactNode }) {
  return (
    <div className="layout">
      <aside>{sidebar}</aside>
      <main>...</main>
    </div>
  );
}
// Layout 不再需要知道 user 或 onAction 的存在

这个模式叫做 "render props via children/slots"。Layout 接收 sidebar 作为 ReactNode，它不关心里面是什么，不需要中转任何数据。数据在顶层（有权访问它的地方）与 UI 片段组合，然后以 ReactNode 的形式注入。

何时你已经超出了 Context 的边界

以下任何一条成立，就说明你需要更专业的状态管理工具：

信号 1：你开始拆分 Context 来优化性能

// 这是在用补丁修复架构问题的信号
const UserDataContext = createContext(null);    // 用户数据（低频）
const UserActionsContext = createContext(null); // 操作函数（不触发重渲染）
const UserStatusContext = createContext(null);  // 在线状态（高频）

// 当你做到第三次拆分时，你已经在手动实现 Zustand 的 selector 系统

信号 2：你需要跨 Context 的派生状态

// 当你需要从多个 Context 计算派生值时，代码开始失控
function useCartSummary() {
  const cart = useContext(CartContext);
  const user = useContext(UserContext);
  const pricing = useContext(PricingContext);

  // 这个 memo 在三个 Context 任一变化时都会重新计算
  return useMemo(() => {
    return computeTotal(cart, user.discount, pricing.taxRate);
  }, [cart, user.discount, pricing.taxRate]);
}

信号 3：你需要在 React 树外部访问或修改状态

WebSocket 消息处理器、定时器回调、Service Worker 通信——这些都发生在 React 组件树之外。Context 对此无能为力，因为它的数据只存在于 React 树内部。

信号 4：调试状态变化变得困难

Context 没有内建的 DevTools 支持、没有时间旅行调试、没有 action 日志。当你开始在 useEffect 里打 console.log 追踪 Context 变化时，架构升级的时机已经到了。

Context 的正确使用模式

明确了边界之后，Context 的正确用法也清晰了：

// 模式 1：静态配置注入
const FeatureFlagsContext = createContext<FeatureFlags>(defaultFlags);

// 模式 2：认证状态（登录/登出是低频操作）
const AuthContext = createContext<AuthState>({ user: null, isLoading: true });

// 模式 3：UI 主题（系统级别的全局配置）
const ThemeContext = createContext<Theme>(defaultTheme);

// 模式 4：路由器内部状态（React Router 就是这样做的）
// 路由不会每秒变化，Context 完全胜任

// 反模式：任何每秒可能变化超过几次的状态
// 反模式：需要细粒度订阅的状态
// 反模式：需要在树外访问的状态
// 反模式：复杂的派生状态计算

Context 是一把精良的手术刀，但你不能用它来盖房子。理解它的边界，是选择正确状态管理工具的第一步。下一章，我们深入 Zustand，一个重新定义"极简"的状态管理库。

Level 3 · 规范怎么定义的（资深）

Context 真正被设计来解决什么

React 官方文档对 Context 的定位一直很克制：它是为"贯穿组件树"的全局数据而设计的，典型场景包括当前主题（theme）、用户登录信息（auth）、国际化语言（locale）。这些数据有一个共同特征——变化极少。用户不会每秒切换主题，语言包不会随鼠标移动而更新。

这个设计约束不是历史局限，而是架构选择。React 团队清楚地知道，当 Context 的 value 发生变化时，所有调用了 useContext 的组件都会重新渲染——无论那个组件实际上有没有用到变化的那部分数据。Context 的传播模型本质上是广播，而不是精准订阅。

// 正确的 Context 用法：低频变化的全局配置
const ThemeContext = createContext<'light' | 'dark'>('light');
const LocaleContext = createContext<string>('zh-CN');
const AuthContext = createContext<{ user: User | null }>({ user: null });

// 这些 Context 的 value 在用户会话期间可能只改变几次
// Context 为此场景而生

Level 4 · 边界与陷阱（所有人）

生产环境常见问题

在实际项目中，本章涵盖的概念最常见的问题包括：

忽视边界条件：在正常路径下工作正常的代码，在异常路径（网络失败、用户快速操作、组件卸载）下可能产生 bug。始终考虑清理和取消逻辑。
过早优化：在没有测量的情况下添加优化代码，增加了复杂度但不一定提升性能。先用 Profiler 确认问题存在，再实施优化。
文档与实际行为的差异：React 的行为在不同版本间可能有微妙差异，尤其是并发模式相关的特性。始终以实际测试结果为准。

本章评分

4.8 / 5 (30 评分)