13.1 状态管理选型指南：不同场景的方案选择

状态管理是 React 应用架构中最核心的决策之一。选对了方案，代码简洁清晰；选错了，后期维护成本会急剧上升。本节不教你具体怎么用某个库，而是帮你建立起一套根据场景选择合适方案的判断框架。

13.1.1 状态管理的本质问题

在 React 中，任何 UI 都由状态驱动。状态管理的核心矛盾可以归纳为两点：

状态的存放位置：放在哪个组件里？是否要提升到全局？
状态的共享与变更：多个组件如何读取同一份数据？如何保证状态变化可预测？

不同的方案其实就是在作用域、易用性、可维护性、性能这四者之间做不同程度的取舍。没有银弹，只有最合适的搭配。

13.1.2 场景驱动的方案分类

从业务场景的复杂度出发，可以将方案分为四个梯队：

第一梯队：纯 React 原生能力（useState + useContext + useReducer）

适用场景：
组件内部局部状态
小型应用或页面（状态总量不大、共享范围窄）
中大型应用中，组件树局部子树的状态共享（例如一个表单区域、一个面板）
代表方案：
useState 管理单个值
useReducer 管理复杂状态逻辑（如多个子值联动）
useContext 跨层级传递，避免 Props Drilling
优势：零依赖，学习成本极低，与 React 深度集成
局限：
Context 更新会导致所有消费者重渲染，需配合 useMemo、组件拆分优化
缺乏中间件、DevTools 调试能力
当状态逻辑复杂且遍布全局时，代码组织困难

判断标准：如果某个状态只被少量（<5 个）组件使用，且不需要全局持久化，直接用原生方案是最简单的。

第二梯队：轻量级外部状态库（Zustand / Jotai / Recoil）

适用场景：
中小型应用的全局状态（主题、用户信息、购物车、全局配置）
需要 API 简洁、学习成本低、无 Provider 包裹的方案
追求高性能渲染（按需更新，避免全量渲染）
代表方案：
Zustand：极简的全局 store，基于发布订阅，不依赖 Context，按 selector 订阅更新
Jotai：原子化状态，类似 useState 的升级版，天然支持异步派生状态
Recoil：Facebook 实验性项目，原子 + 选择器，与 React 并发模式天然兼容（但维护力度弱）
优势：
样板代码极少，上手快
通常没有 Provider 包裹，组件树更干净
精确更新：只有使用到的组件在相关状态变化时才重渲染
局限：
缺乏规范化的中间件体系（如 Redux 的中间件生态）
在超大型团队中，过于灵活可能导致状态设计杂乱
Recoil 已进入维护模式，不建议新项目选用

判断标准：如果团队追求开发效率，应用规模中等，且希望避免 Redux 的样板代码，Zustand 或 Jotai 是目前的最佳平衡点。

第三梯队：重量级状态管理（Redux + Redux Toolkit）

适用场景：
大型、复杂的单页应用（例如电商后台、金融系统、多人协作工具）
需要可预测的状态变更，有严格的状态变更流程（Action → Reducer）
团队规模较大，需要统一的状态管理规范和强大的 DevTools 调试能力
需要成熟的中间件生态（如 Redux Saga、Redux Observable 处理异步流）
代表方案：
Redux Toolkit（RTK）：官方推荐的现代 Redux 编写方式，内置 immer、中间件、实体适配器
RTK Query：集成在 Redux Toolkit 中的数据请求与缓存方案，替代手写 thunk
优势：
单一数据源：整个应用状态以一棵对象树的形式存储
可预测：状态只能通过 dispatch action 触发纯 reducer 更新
强大的 DevTools：时间旅行调试、状态快照、action 日志
规范性强：明确的模式约束，让不同开发者写出的代码风格统一
庞大的社区与教程积累
局限：
学习曲线相对陡峭（即使 RTK 已大幅简化）
对于小应用而言，重量级过重，产生了不必要的抽象
过度集中可能导致过大 store，需通过代码分割或切片组织

判断标准：当你的应用状态像“全局数据库”，有大量跨页面、跨模块的状态需要协同管理，且有复杂的异步流程时，Redux Toolkit 是最稳妥的选择。

第四梯队：混合方案与特定领域方案

适用场景：
服务端状态主导的应用，客户端状态很少
特定领域已经提供了成熟方案，如 URL 状态代替部分全局状态
代表方案：
TanStack Query / SWR：专门管理服务端缓存状态（请求数据、缓存、过期、重新获取），极大减少了手写客户端状态的需求。实际上，很多应用 80% 的全局状态其实是服务端数据的缓存，用这类库可以直接“消灭”这些状态。
URL 状态：分页、筛选、搜索关键词等，直接放在 URL 查询参数中，由 React Router 管理。这样做的好处是页面刷新不丢失，且支持分享链接。
Forms 专用状态：复杂表单状态直接用 React Hook Form 或 Formik 管理，不放入全局 store。
优势：
充分利用各种方案的最强项
避免将所有状态塞进一个 store，保持关注点分离
局限：
需要团队对不同方案有清晰的认识和边界划分，否则容易混乱

判断标准：当你的状态可以被明确归类为“服务端数据”“表单数据”“UI 临时状态”时，不要犹豫，用专门的工具管理专属状态，全局 store 只负责真正跨模块共享的业务状态。

13.1.3 决策树：如何快速做选择

你可以按以下顺序问自己几个问题，快速锁定方案：

这个状态只在单个组件内使用吗？

是 → useState / useReducer
否 → 继续

这个状态需要被组件树中相隔很远的组件使用吗？

是，但仅限一棵有限的子树（如一个功能模块） → useContext + useReducer 封装
是，且需要在全局任意地方访问 → 继续

这个状态是否主要是服务端数据的缓存？

是 → TanStack Query / SWR（优先），并尽量少存客户端全局状态
否 → 继续

应用规模有多大？团队有多少人？

小型（1-3 人，简单业务） → Zustand 或 Jotai
中大型（5+ 人，复杂业务，长期维护） → Redux Toolkit（RTK） + RTK Query
超大型（模块化、微前端） → 可根据模块隔离使用不同方案，但整体上倾向 Redux Toolkit 保证一致性

团队已有的技术栈或历史债务？

如果是遗留项目已有 Redux，谨慎迁移，优先使用 RTK 替代旧式 Redux
如果团队对某方案非常熟悉，在大体匹配场景的前提下，优先考虑团队熟悉度，降低沟通成本

13.1.4 典型场景示例与推荐搭配

| 场景类型 | 推荐方案 | 原因 |
|---------|---------|------|
| 个人博客 / 简单招商页 | React Context + useState | 状态极简，无需引入第三方库 |
| 中型电商前端 | Zustand（购物车、用户） + TanStack Query（商品列表、详情） | 开发快速，性能好 |
| 企业后台管理系统（动态路由、权限、复杂表单） | Redux Toolkit（全局配置、权限） + React Hook Form（表单） + TanStack Query（列表、详情） | 规范性、调试能力、表单性能兼顾 |
| 实时数据大屏 / 协作工具 | Redux Toolkit + 中间件（WebSocket 集成） | 数据流复杂，需要强约束和 DevTools |
| 跨多子应用的大型系统（微前端） | 每个子应用独立选择，但全局共享主题/用户信息可用简单的订阅模式或 Zustand | 避免全局 Store 单点，但共享最小量状态 |

13.1.5 常见误区与避坑

一切皆全局状态：把所有数据都放进全局 store，导致 store 臃肿不堪，任何小改动都触发大面积渲染。应遵循“就近原则”，能放局部就局部。
过早优化选型：应用初期不必要导入 Redux。先用原生 Hooks，当感到痛点时再引入工具库，此时需求已经明确。
Context 取代所有状态管理：React Context 不是为高频更新设计的，如果用 Context 管理频繁变化的状态（如计数器、动画值），会引发性能灾难。
盲目追求新库：Zustand、Jotai 虽好，但若团队已深度掌握 Redux，且项目特征吻合 Redux 场景，不必强行切换。

13.1.6 小结

React 状态管理没有万能答案，而是一套组合拳。核心原则是：

局部状态优先，用最简单的 useState；
服务端数据用专用缓存库，别手动转换成本地状态；
真正全局且业务关键的状态，再引入外部状态管理库；
选择与团队规模和业务复杂度匹配的方案，让工具为你服务，而不是被工具束缚。

在后续章节中，我们将逐一展开 Zustand、Redux Toolkit 等方案的具体用法，为你提供可以直接落地的代码示例。