react 的状态管理

一、React 状态管理的四大层级

层级	用途	使用方式	描述
局部 UI 状态	表单输入、Modal 显示	useState	-
组件级业务状态	复杂表单、业务逻辑	useReducer	-
跨组件状态共享	用户信息、主题、权限	Context	易引发全局重渲染
应用级大状态	整个系统的业务数据	Zustand / Jotai / Redux Toolkit	大项目标配

二、React 内置状态管理（Hooks）的进阶用法

1、useState 的进阶

• 避免频繁 re-render 的优化
  • 避免在组件内部创建大型对象或数组作为初始 state
  • 使用 lazy initialization：const [list] = useState(() => computeBigList());
• 批量更新（React 18+ 自动批处理）

setCount(c => c + 1);
setFlag(f => !f);

2、useReducer——更可控、更可测试的状态管理

适用场景：

• 复杂业务逻辑
• 多个状态需要打包管理（如表单内多字段）
• 需要可预测性（与 Redux 类似）

例子：

function reducer(state, action) {switch(action.type) {case 'change_name':return { ...state, name: action.value };case 'submit':return { ...state, loading: true };}
}

3、Context（真正的使用方式）

Context 经常被误用！

❗ 避免将“大状态”全部塞入 Context。不要用来存储：列表数据、表格数据、表单、业务状态。

因为：
Context 更新会让所有子组件无条件重新渲染。

Context 的最佳用途是：

• 主题（theme）
• 用户权限（role）
• 国际化（i18n）
• 全局配置（config）

三、React 大型项目需要使用第三方状态管理

为什么 React 大型项目需要使用第三方状态管理？
 
【答】：因为 React 内置状态管理 无法优雅解决：

• 跨页面共享复杂业务状态
• 多 Tab 共享状态
• 同时管理 Server 数据 + Client 状态
• 频繁触发大组件树重渲染
• 数据依赖（多个组件依赖同一业务状态）

1、现代项目的主流状态管理：Zustand（最推荐）

Zustand 已经成为 React 项目的事实标准，原因：

• 写法和 Hooks 完全一致（天然组合）
• 极低心智负担
• 默认支持选择性订阅（避免无意义重渲染）
• 简单但足够强大

示例：

const useUserStore = create((set) => ({user: null,setUser: (u) => set({ user: u })
}));const user = useUserStore((state) => state.user);

Zustand 的关键优势：

• 按需订阅，不会导致整个组件树重渲染 useUserStore(state => state.user);。
• 只有依赖 user 的组件会更新。

2、Jotai（原子化状态管理）

适合复杂 UI 场景，代表：

• 在线表单生成器
• 低代码平台
• 多维度的 UI 状态拆分

核心理念：

• 将每个状态拆分成 “原子”

像这样：

const countAtom = atom(0);
const doubledAtom = atom((get) => get(countAtom) * 2);

3、Redux Toolkit（大企业级应用还在大量使用）

优点：

• 思想成熟、可预测性最高
• 大中型团队标准化程度最高
• 调试工具（DevTools）最强
• 异步流程（RTK Query）一流

如果你的项目有：

• 数十个模块
• 需要严格可控的状态流动
• 大量 API 调用
• 中台、后台系统

那么，Redux Toolkit 是企业级最佳选择。

关于 Redux 的深度学习请看： redux 学习
关于 Redux Toolkit 的深度学习请看：Redux Toolkit 学习

4、React Query：管理“服务器状态”

注意：React Query 不是状态管理库，它是“服务器状态管理库”。

适合管理：

• 异步请求
• 列表、分页、缓存
• loading/error
• 请求重试、缓存失效
• 后端数据同步

在现代 React 架构中：

• 本地状态 → Zustand/Jotai/Redux
• 服务器状态 → React Query

完美互补。

React Query 的使用请看：前端使用 React Query 管理“服务器状态”

四、React 19 + RSC（Server Components）新趋势

React 19 推出的 Server Components 技术重构了数据获取方式。

实际趋势：

• 数据获取不再放在 Client
• 客户端组件不需要大量状态管理
• Context/Redux/Zustand 的使用比以前更轻

未来写法将越来越像：

// RSC：在服务端获取数据，直接返回 UI
export default async function Page() {const data = await fetch(...);return <List items={data} />
}

状态管理将更多用于：

• UI 状态（dialog open）
• 临时状态（表单、实时输入）
• 客户端交互（拖拽、可视化）
• 大部分业务数据会在 RSC 层完成。

五、如何选择最佳状态管理方案？

应用级别	最佳状态管理方案
小型应用	useState、useReducer、Context（仅用来做 UI 主题等）
中型应用（推荐）	Zustand（本地状态）、React Query（服务器数据）
后台系统 / 中台 / 大型业务	Redux Toolkit（本地）、RTK Query（服务器数据）
可视化、低代码平台	Jotai（原子化）
Next.js（未来趋势）	Server Components（业务数据）、Client Hooks 仅用于 UI 交互