React Context 适合解决什么问题？有什么性能注意点？

简化版

Context 用于跨层级传递数据，适合主题、语言、当前用户、权限等低频全局信息。Context value 变化会让消费它的组件重新渲染，频繁变化的大状态不适合全部塞进一个 Context。

详细版

示例：

const ThemeContext = createContext('light');

function App() {
  return (
    <ThemeContext.Provider value="dark">
      <Page />
    </ThemeContext.Provider>
  );
}

消费：

const theme = useContext(ThemeContext);

Context 解决的是 props drilling，不是完整状态管理方案。复杂状态仍可能需要 Redux、Zustand、Jotai、React Query 等工具。

完整版教学

一、Context 解决跨层传值

如果顶层主题要传到很深的按钮组件，中间层组件只是转发 props，会产生 props drilling。Context 可以让深层组件直接读取上层 Provider 的值。

它适合“很多组件需要读，但不频繁变化”的数据。

二、Provider value 的引用稳定性

如果 Provider 每次 render 都创建新对象：

<Provider value={{ user, logout }}>

即使 user 没变，value 引用也变了，消费者可能重新渲染。可以用 useMemo 稳定 value，或者拆分多个 Context。

三、Context 的性能边界

Context value 一变，使用该 Context 的消费者都会更新。把一个巨大 store 放进单个 Context，里面任何字段变化都可能影响大量组件。

解决思路包括拆分 Context、使用 selector 型状态库、把频繁变化状态放到更局部的位置。

四、面试追问与工程落地

常见追问是“Context 能不能替代 Redux”。简单全局数据可以，但复杂状态管理不只是传值，还涉及状态更新规范、中间件、调试、异步缓存、局部订阅等。Context 是基础能力，不是银弹。

工程中主题、国际化、权限、当前登录用户适合 Context；高频表单输入、动画状态、列表 hover 状态不适合放全局 Context。

五、用订阅范围估算 Context 更新成本

useContext 会读取并订阅调用组件上方最近的 Provider。React 使用 Object.is 比较新旧 value；value 变化时，所有读取该 Context 的后代都可能重新渲染，即使这些消费者外面包了 memo，也不能阻止它们接收新 Context。

Provider value 变化
  ├─ Consumer A：读取 theme → 重新渲染
  ├─ Consumer B：读取 user  → 重新渲染
  └─ 普通后代 C：未读取 Context → 不因 Context 直接更新

假设一个 Context 有 100 个消费者，value 每秒变化 10 次，最坏可能触发每秒 1000 次消费者函数执行。这个数字只是成本上界，实际还受批处理和子树结构影响；它说明为什么鼠标坐标、输入框值这类高频数据不应直接广播给大范围消费者。

方案	订阅粒度	适用数据	主要代价
单个大 Context	整个 value	低频、小规模共享	任一字段变更可能波及全部消费者
拆分多个 Context	按领域拆分	theme、user、locale 分离	Provider 层级和接口数量增加
Context + reducer	读状态并传 dispatch	中等复杂度子树状态	仍没有字段级 selector
selector 型外部 store	按选中切片	高频、大规模共享	引入库和额外状态模型

六、Provider 设计要同时稳定值和写入口

只把对象包进 useMemo 并不自动解决架构问题；如果依赖中的 user 每次都是新对象，缓存仍会失效。更可靠的做法是拆分状态 Context 与操作 Context，让只需要 dispatch 的组件不订阅不断变化的状态，并把 Provider 放到真正需要共享的最小子树上。

const state = useMemo(() => ({ user, theme }), [user, theme]);
<AuthState value={state}>
  <AuthActions value={actions}>{children}</AuthActions>
</AuthState>

Context 的默认值只在组件上方没有匹配 Provider 时使用，不会在 Provider 传入 undefined 时自动回退。测试中可以用默认值做独立渲染，但业务代码仍应明确 Provider 缺失是允许状态还是配置错误。

记忆钩子：Context 优化不是“给 value 套 useMemo”这么简单，而是缩小 Provider 范围、拆分变化频率、减少消费者订阅面。

七、常见误区与追问

误区：Context value 的内容相同就不会更新消费者。 React 按 Object.is 比较 value，重新创建的对象即使字段相同也不是同一引用。
误区：给消费者套 React.memo 就能屏蔽 Context 更新。 memo 只比较 props，组件订阅的 Context 变化仍会触发新值传播。
误区：Context 就是 Redux 的轻量替代品。 Context 负责传递与订阅，复杂状态库还提供 selector、中间件、调试和外部存储等能力。
追问：拆分 Context 为什么可能更快？ 消费者只订阅自己需要的领域，主题变化不会连带刷新只读取用户信息的组件。
追问：Provider 应该放得越高越好吗？ 不应；范围越高潜在消费者越多，局部业务状态应放在最近共同祖先。
追问：传入 undefined 会使用 createContext 默认值吗？ 不会，匹配到 Provider 后返回的就是其 value，包括 undefined。
追问：什么时候不该用 Context？ 只有少数层传递时优先 props 或 children，高频字段级订阅则考虑状态下沉或 selector 型 store。

八、加强记忆

Context 是“跨层级广播”，适合低频共享信息。value 变化会影响消费者，复杂高频状态不要一股脑塞进一个 Context。

优化时按“缩小 Provider、拆分变化频率、减少订阅者”推演，比只背 useMemo 更完整。

简化版

详细版