4、Context API 实战：React Context 工作原理、Provider/Consumer 模式、避免不必要的重渲染

说到 React 的状态管理，很多人第一反应就是 Redux。但说实话，在真实项目中，有大量场景根本用不着那么重的方案。Context API 就是 React 官方给我们的一把「轻量级手术刀」—— 用好了，代码干净利落；用不好，性能直接翻车。

我记得刚接手一个老项目时，看到 props 层层传递了七八层，中间还有几个组件根本不用这些数据，纯粹当「二传手」。我当时就想，这不就是 Context 的典型场景吗？

4.1 Context 的工作原理

Context 的设计思路其实很简单：在组件树中开辟一条「直达通道」。数据不需要一层层传递，任何层级的组件都能直接拿到。

它的底层其实维护了一个「订阅-通知」机制。当 Provider 的 value 发生变化时，React 会通知所有订阅了这个 Context 的组件重新渲染。嗯，这里要注意——是「所有」订阅者，不管它们用没用具体数据。

// 创建 Context
const ThemeContext = React.createContext('light');

// 提供数据
function App() {
  const [theme, setTheme] = useState('dark');
  return (
    <ThemeContext.Provider value={{ theme, setTheme }}>
      <Toolbar />
    </ThemeContext.Provider>
  );
}

// 消费数据
function ThemedButton() {
  const { theme, setTheme } = useContext(ThemeContext);
  return (
    <button
      style={{ background: theme === 'dark' ? '#333' : '#fff' }}
      onClick={() => setTheme(theme === 'dark' ? 'light' : 'dark')}
    >
      切换主题
    </button>
  );
}

4.2 Provider/Consumer 模式

Provider 和 Consumer 是 Context 的两大核心角色。我习惯把 Provider 想象成一个「广播站」，Consumer 就是「收音机」。

Provider：数据的源头

Provider 可以嵌套使用，内层的 Provider 会覆盖外层的同名 Context 值。这个特性在实现「局部覆盖」时特别有用。

// 多层 Provider 嵌套
<ThemeContext.Provider value="dark">
  <div>
    <ThemedButton />  {/* 拿到 dark */}
    <ThemeContext.Provider value="light">
      <ThemedButton />  {/* 拿到 light */}
    </ThemeContext.Provider>
  </div>
</ThemeContext.Provider>

Consumer：三种消费方式

方式	适用场景	注意事项
useContext (Hooks)	函数组件，最推荐	只能在组件顶层调用
Context.Consumer	类组件或需要 render props	嵌套多了可读性差
contextType	类组件，只能订阅一个	已不推荐使用

4.3 避免不必要的重渲染

这是 Context 最容易被坑的地方。我曾经在一个实时数据监控项目里，把整个状态对象都塞进 Provider 的 value 里。结果呢？只要有一个字段变了，所有订阅组件全部重渲染。页面直接卡成 PPT。

为什么会这样？因为 React 对 Context 的 value 做的是引用比较。每次渲染时，如果 value 是新对象，所有 Consumer 都会收到通知。

避坑指南：四个实战技巧

1. 拆分 Context

   把不相关的状态拆成多个 Context。比如主题和用户信息，它们变化频率不同，就应该分开。

   // 错误：一个 Context 包罗万象
   const AppContext = React.createContext({ theme, user, settings });
   
   // 正确：按职责拆分
   const ThemeContext = React.createContext('light');
   const UserContext = React.createContext(null);
   const SettingsContext = React.createContext({});

2. 使用 useMemo 稳定 value 引用

   每次渲染都创建新对象，是性能杀手。用 useMemo 缓存 value。

   function App() {
     const [theme, setTheme] = useState('light');
     const [count, setCount] = useState(0);
   
     // 稳定 value 引用
     const themeValue = useMemo(() => ({ theme, setTheme }), [theme]);
   
     return (
       <ThemeContext.Provider value={themeValue}>
         <button onClick={() => setCount(c => c + 1)}>
           计数: {count}
         </button>
         <ThemedPanel />
       </ThemeContext.Provider>
     );
   }

3. 用 React.memo 包裹消费组件

   如果组件只依赖 Context 中的部分数据，用 memo 阻止无关更新。

   const ThemedButton = React.memo(function ThemedButton() {
     const { theme } = useContext(ThemeContext);
     return <button className={theme}>按钮</button>;
   });

4. 分离「读」和「写」

   把只读数据和修改方法分开到不同的 Context。这样修改方法变化时，只读组件不会受影响。

   // 只读 Context
   const ThemeValueContext = React.createContext('light');
   // 写操作 Context
   const ThemeActionsContext = React.createContext({ toggle: () => {} });
   
   function App() {
     const [theme, setTheme] = useState('light');
     const actions = useMemo(() => ({
       toggle: () => setTheme(t => t === 'light' ? 'dark' : 'light')
     }), []);
   
     return (
       <ThemeValueContext.Provider value={theme}>
         <ThemeActionsContext.Provider value={actions}>
           <ThemedPanel />
         </ThemeActionsContext.Provider>
       </ThemeValueContext.Provider>
     );
   }

4.4 Context 与 useReducer 搭配

当状态逻辑变得复杂时，我习惯把 Context 和 useReducer 组合使用。这样既能享受 Context 的「直达通道」，又能用 reducer 管理复杂的状态转换。

// 定义 reducer
function todoReducer(state, action) {
  switch (action.type) {
    case 'ADD':
      return [...state, action.payload];
    case 'TOGGLE':
      return state.map(todo =>
        todo.id === action.id ? { ...todo, done: !todo.done } : todo
      );
    default:
      return state;
  }
}

// 组合 Context + useReducer
function TodoProvider({ children }) {
  const [todos, dispatch] = useReducer(todoReducer, []);
  const value = useMemo(() => ({ todos, dispatch }), [todos]);

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

// 消费组件
function TodoList() {
  const { todos, dispatch } = useContext(TodoContext);
  return (
    <ul>
      {todos.map(todo => (
        <li key={todo.id}>
          <span style={{ textDecoration: todo.done ? 'line-through' : 'none' }}>
            {todo.text}
          </span>
          <button onClick={() => dispatch({ type: 'TOGGLE', id: todo.id })}>
            切换
          </button>
        </li>
      ))}
    </ul>
  );
}

4.5 Context 知识体系总览

下面这张图总结了 Context 的核心脉络，从创建到消费，再到性能优化，一目了然。

4.6 什么时候用 Context？

不是所有状态都适合用 Context。我总结了一个简单的判断标准：

场景	推荐方案	原因
主题、语言、用户信息	Context	全局共享，变化频率低
表单状态、页面局部数据	Context + useReducer	需要局部共享，逻辑复杂
高频更新的全局状态	Redux / Zustand	Context 会导致大量重渲染
组件内部状态	useState	不需要共享，用 Context 反而增加复杂度

说白了，Context 就是 React 给我们的「轻量级状态总线」。用好了，代码简洁高效；用不好，性能问题够你排查半天。记住四个字：按需拆分。这是避免重渲染的终极心法。