React中的Context与状态管理边界
React 中 Context、局部状态与外部状态管理方案各自适合解决什么问题。
[!info] related notes
- 所属 MOC: React MOC
- 相关概念: react-use-context, react-use-state, react-use-reducer
- 延伸阅读: react-state-management-selection
React中的Context与状态管理边界
在 React 里，Context、组件本地状态和外部状态管理库并不是同一层问题。很多架构混乱，都是因为把“传递”问题和“状态演化”问题混在了一起。
为什么要放在一起理解
因为很多人一学会 useContext，就会忍不住把所有共享数据都塞进去，但 Context 解决的核心只是“跨层传值”，不是完整状态管理。
三层最常见的状态来源
组件本地状态
适合只在当前组件或很小范围内使用的状态。
Context
适合跨层传递共享配置或范围明确的数据。
外部状态管理
适合复杂共享状态、跨页面业务流程、调试追踪和更明确的状态组织。
例如 zustand、Redux Toolkit、TanStack Query 等。
为什么很多项目会在这里混乱
因为团队常常把这些问题混成一类：
- 数据到底由谁持有
- 数据怎么跨层传递
- 数据怎么演化、缓存、调试
而 Context 只解决了其中一部分。
一个更实用的拆法
面对一份状态时，先问三件事：
- 它只在局部组件里用吗
- 它只是需要跨层传值吗
- 它是不是已经复杂到要集中组织、调试、缓存或跨页面共享
回答不同，方案就不同。
一条实用判断线
- 只在当前组件用：本地状态
- 只是跨层传值：Context
- 共享范围大、业务流程复杂、需要集中组织：外部状态管理
一个常见反例
如果把以下内容全部塞进一个大 Context：
- 当前主题
- 登录用户
- 表单草稿
- 列表数据
- loading 状态
- 翻页状态
短期看像是“统一了”，长期通常会变成：
- Provider value 频繁变化
- 消费者拆分困难
- UI 状态和业务状态边界混乱
常见误区
- 用 Context 扛所有全局状态
- 还没形成共享需求，就过早引入重量级状态管理
- 把服务器状态、UI 状态、业务状态全混在一起
最短记忆方式
Context 解决“怎么传”，状态管理解决“怎么组织和演化”。
面试要点
来自 react-context-replace-state-management-interview-question 的面试视角整理。
一句话回答
Context 可以解决一部分共享数据的跨层传递问题，但它并不天然等于完整状态管理；当状态规模、更新复杂度和调试需求上来后，通常还需要更明确的状态管理方案。
最稳的回答主线
- Context 更擅长共享配置和范围明确的数据
- 它解决的是“怎么传”
- 完整状态管理更关注“怎么组织、怎么演化、怎么调试”
一个更完整的面试表达
可以这样答：
我不会简单回答 Context 能或不能替代状态管理。更准确地说，Context 主要解决的是“跨层传值”问题，比如 theme、locale、当前用户这类范围明确的数据。
但完整状态管理还涉及状态如何拆分、如何演化、如何调试、如何处理复杂更新流程。所以当状态规模和复杂度上来后，Context 往往不够用，至少不够优雅。
什么场景适合 Context
- 主题
- 国际化
- 登录用户
- 模块级共享配置
为什么它不能无脑扩张
如果把大量频繁变化的状态都堆进一个大 Context：
- Provider value 经常变化
- 消费者范围变大
- 状态边界会越来越糊
这时问题就不是“能不能传到”，而是“是不是好维护”。
一个更工程化的结论
Context 是共享通道，不是默认的全局状态管理终点。
最短记忆方式
Context 更像通道，不是整套状态管理体系。