29.4 Context 穿透导致的全量重渲染问题

问题场景

React Context 是解决跨层级组件通信的利器，但它也自带一个极易踩中的性能陷阱：Context 的值一旦发生变化，所有消费该 Context 的组件都会重渲染，即使该组件实际只用到了 Context 中的部分数据。如果你的 Context 里存储了多个互不相关的状态，而各个子组件只消费其中某一个，那么任何一个状态的更新都会触发所有消费者重新渲染。

// 创建一个包含多个状态的 Context
const AppContext = createContext();

function AppProvider({ children }) {
  const [user, setUser] = useState(null);
  const [theme, setTheme] = useState('light');
  const [notifications, setNotifications] = useState([]);

  const value = { user, setUser, theme, setTheme, notifications, setNotifications };
  return <AppContext.Provider value={value}>{children}</AppContext.Provider>;
}

// 组件 A 只用到 theme
function ThemeToggle() {
  const { theme, setTheme } = useContext(AppContext);
  return <button onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>Theme: {theme}</button>;
}

// 组件 B 只用到 user
function UserAvatar() {
  const { user } = useContext(AppContext);
  return <img src={user?.avatar} alt="avatar" />;
}

当 user 更新时，ThemeToggle 也会重渲染，尽管它完全不依赖 user。在组件树较深、消费者较多时，这种“被牵连的重渲染”会迅速累积，造成明显的性能问题。

根因分析

原因出在两个方面：

Context 的 value 是一个对象：每次 AppProvider 渲染时，value 都是新创建的对象引用（即使内容完全相同），React 以引用比较来判断 Context 是否变化，所以任何状态更新都会生成新的 value 对象，触发所有消费者更新。
React 的渲染传播机制：Context 的更新会跳过中间组件的 shouldComponentUpdate 或 React.memo，直接深入所有消费者。也就是说，即使你给中间组件包了 memo，也无法拦截 Context 变化引发的子树重渲染。

解决方案

1. 拆分 Context，按领域隔离

这是最直接也是最推荐的做法。将多个独立的状态拆到不同的 Context 中，每个 Context 只管理一个关注点。

const UserContext = createContext();
const ThemeContext = createContext();
const NotificationContext = createContext();

function AppProvider({ children }) {
  const [user, setUser] = useState(null);
  const [theme, setTheme] = useState('light');
  const [notifications, setNotifications] = useState([]);

  return (
    <UserContext.Provider value={{ user, setUser }}>
      <ThemeContext.Provider value={{ theme, setTheme }}>
        <NotificationContext.Provider value={{ notifications, setNotifications }}>
          {children}
        </NotificationContext.Provider>
      </ThemeContext.Provider>
    </UserContext.Provider>
  );
}

现在 ThemeToggle 只消费 ThemeContext，user 的更新不会再触发它的重渲染。这种拆分也让代码结构更清晰，符合单一职责原则。

2. 用 `useMemo` 稳定 value 引用（但只能解决自身渲染导致的问题）

很多人以为只要把 value 用 useMemo 包裹就能避免重渲染：

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

这确实能避免因 AppProvider 自身重渲染而创建新的 value 引用，但当 user 或 theme 变化时，value 仍然会变，消费者依然会更新。所以它只能解决无关状态（如 Provider 内的其他 useState）导致的重复创建问题，不能解决前述的“一个状态更新牵连其他消费者”的核心问题。

3. 状态与更新函数分离传递

更进一步的优化是将状态和更新函数放到不同的 Context 或者采用选择器模式。更新函数通常是稳定的（setState 函数引用不变），将它们分开可以避免部分情况下的重渲染。

const UserStateContext = createContext();
const UserDispatchContext = createContext();

function UserProvider({ children }) {
  const [user, setUser] = useState(null);
  return (
    <UserStateContext.Provider value={user}>
      <UserDispatchContext.Provider value={setUser}>
        {children}
      </UserDispatchContext.Provider>
    </UserStateContext.Provider>
  );
}

这样只读状态的组件可以从 UserStateContext 取值，只触发更新的组件（比如一个按钮）可以从 UserDispatchContext 获取 setUser，而 setUser 引用稳定，永远不会触发后者的重渲染。

4. 外部状态管理库的“选择器”模式

当项目规模更大，Context 拆分会变成“Context 地狱”时，可以考虑使用状态管理库。像 Redux（useSelector）、Zustand（自定义 selector）、Jotai（原子化自动依赖追踪）都提供了细粒度的订阅机制：

// Zustand 示例
const useStore = create((set) => ({
  user: null,
  theme: 'light',
  setUser: (user) => set({ user }),
  setTheme: (theme) => set({ theme }),
}));

function ThemeToggle() {
  const theme = useStore((state) => state.theme);
  const setTheme = useStore((state) => state.setTheme);
  // 只会因为 theme 变化而重渲染
}

这些库在底层做了精细化依赖追踪，只有被选中的状态变化时组件才会更新，彻底避免了 Context “一刀切”式的性能问题。

5. `useContextSelector`（即将内置，目前需要第三方库）

React 团队正在实验原生的 Context 选择器功能 useContextSelector，目前可通过 use-context-selector 这个第三方库提前使用：

import { createContext, useContextSelector } from 'use-context-selector';

const AppContext = createContext();

function ThemeToggle() {
  const theme = useContextSelector(AppContext, (v) => v.theme);
  // 只有 theme 变化时才重渲染
}

它通过订阅特定字段实现精准更新，是未来 Context 性能更优的解。

实际排查方法

当怀疑性能问题与 Context 相关时，可以通过 React DevTools 的 Profiler 录制交互过程，检查是否有大量组件在一次状态更新中被标记为重渲染。或者临时给 Consumer 组件包裹 React.memo 并配合 useMemo 验证是否仍然出现不必要渲染（但切记 memo 挡不住 Context 变化）。

最佳实践总结

按业务领域拆分 Context，避免一个大而全的“全局状态池”。
将状态和更新函数分离到不同的 Context。
对于高频更新（如动画帧、输入值），避免通过 Context 传递，改用局部状态或状态管理库。
当 Context 嵌套过深、性能敏感时，果断使用 Zustand / Jotai 等轻量级外部库，换取更细粒度的渲染控制。
编写自定义 Hooks 封装 useContext 逻辑，方便未来无痛迁移优化方案。