一、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 过度膨胀。