一、React 状态管理全家桶总览
可以一句话先抛给面试官：
React 状态管理 = 本地状态 + 跨组件状态 + 全局状态
二、核心方案对比表（重点）
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| useState | 简单、直观、零成本 | 只能组件内 | 表单、UI 状态 |
| useReducer | 逻辑集中、可预测 | 样板代码偏多 | 复杂组件状态 |
| Context | 原生、无需三方库 | 性能差、难维护 | 主题、语言 |
| Redux | 可预测、生态成熟 | 心智负担重 | 中大型项目 |
| Redux Toolkit | 语法简洁、官方推荐 | 仍偏全局 | 企业级项目 |
| MobX | 响应式、上手快 | 隐式更新 | 快速业务开发 |
| Zustand | 轻量、Hooks 风格 | 生态较小 | 中小项目 |
| Recoil | 原子化、React 思维 | 社区停滞 | 组件级共享 |
| Jotai | 极简、可组合 | 学习曲线 | 细粒度状态 |
| URL State | 可分享、可回溯 | 不适合复杂数据 | 查询条件 |
三、逐个深挖（面试官最爱问的）
1️⃣ useState（一定要说，但别停在这）
优点
- 最简单
- React 内置
缺点
- 只能组件内
- 组件层级深就失控
应用场景
- 弹窗开关
- 输入框
- loading 状态
面试话术
useState 适合组件私有状态，不建议用来做跨组件通信。
2️⃣ useReducer（被低估的利器）
优点
- 状态变更可预测
- 逻辑集中
缺点
- 写起来啰嗦
应用场景
- 表单状态
- 多步骤流程
面试话术
当状态变化有明确动作时，我会优先用 useReducer，而不是堆多个 useState。
3️⃣ Context（面试陷阱点）
优点
- 原生
- 无依赖
缺点
- value 变化 → 全量重渲
- 不适合频繁更新
应用场景
- 主题
- 国际化
- 登录态（只读）
面试话术
Context 更适合低频、全局只读状态，不适合复杂业务状态。
4️⃣ Redux（面试官老朋友）
优点
- 单一数据源
- 可预测
- 调试友好
缺点
- 模板代码多
- 上手成本高
应用场景
- 中大型应用
- 多人协作
面试话术
Redux 的优势在于可维护性，而不是开发效率。
5️⃣ Redux Toolkit（现在主流答案）
优点
- 减少样板代码
- 官方推荐
- 内置 immer
缺点
- 仍是全局 store
应用场景
- 企业级后台
- 状态复杂
面试话术
新项目我会优先使用 Redux Toolkit，而不是原始 Redux。
6️⃣ MobX（争议型）
优点
- 响应式
- 写起来快
缺点
- 隐式依赖
- 调试困难
应用场景
- 原型开发
- 快速迭代项目
面试话术
MobX 更偏开发效率，但在多人协作中可维护性需要规范约束。
7️⃣ Zustand（近几年面试加分）
优点
- 极简
- 无样板代码
- Hooks 风格
缺点
- 生态不如 Redux
应用场景
- 中小型项目
- React Hooks 项目
面试话术
Zustand 在性能和简洁性上很平衡，适合不想引入 Redux 的项目。
8️⃣ Recoil / Jotai（高手才提）
优点
- 原子化
- 精准更新
缺点
- 社区不稳定（Recoil）
应用场景
- 组件级共享状态
面试话术
原子化状态在复杂组件树中能显著减少无效渲染。
四、面试官最爱追问：你怎么选？
🎯 标准选型口诀（建议背）
小 → useState
复杂组件 → useReducer
低频全局 → Context
复杂业务 → Redux Toolkit
轻量全局 → Zustand
五、结合你背景的“高分回答模板”
在性能平台这种多页面、多筛选条件、跨组件通信频繁的场景，我会用 Redux Toolkit 管理核心业务状态，同时把局部 UI 状态留在组件内部，用 useState 或 useReducer，避免全局 store 过度膨胀。
