13.1 Pinia 核心体系

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

13.1.1 状态管理的本质问题

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

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

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

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 决策树：如何快速做选择

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

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

• 是 → useState / useReducer
• 否 → 继续

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

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

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

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

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

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

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

• 如果是遗留项目已有 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 常见误区与避坑

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

13.1.6 小结

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

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

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