在 React Native 生态中，状态管理并不存在唯一标准答案，而是随着项目规模、团队背景和技术演进不断变化。
下面我按照使用场景与复杂度，对目前主流、仍然值得学习和使用的状态管理方案做一次系统梳理。
一、React 官方能力（必须掌握的基础）
1. useState / useReducer
适用场景
- 组件内部状态
- 简单页面逻辑
- UI 状态（展开/收起、选中态等）
特点
- 无额外依赖
- 可预测、易调试
- 不适合跨页面、跨模块共享
const [count, setCount] = useState(0);
2. Context + Hooks
适用场景
- 主题（Theme）
- 语言（i18n）
- 用户信息（小规模）
优点
- 官方方案
- 与 React 深度融合
不足
- 更新会导致整棵子树 re-render
- 大规模使用容易导致性能问题
👉 通常不建议把 Context 当作“Redux 替代品”。
二、经典全局状态管理（仍然主流）
3. Redux / Redux Toolkit（RTK）
当前推荐方式：Redux Toolkit
适用场景
- 中大型应用
- 状态复杂、来源多
- 多人协作项目
优势
- 强约束、可预测
- DevTools 极其成熟
- RTK 大幅减少模板代码
const slice = createSlice({
name: 'user',
initialState,
reducers: {
setUser(state, action) {
state.info = action.payload;
}
}
});
生态
redux-persistredux-thunk/redux-saga- 与 RN 适配成熟
4. MobX / MobX-State-Tree
适用场景
- 偏 OOP 思维
- 状态频繁变化
- 希望减少样板代码
特点
- 响应式（observable）
- 心智模型简单，上手快
不足
- 隐式更新，调试成本较高
- 大型团队一致性较难保证
三、轻量级现代状态管理（近几年主流）
5. Zustand（非常推荐）
适用场景
- 中小型项目
- RN 新项目
- 希望简单、低心智负担
优势
- API 极简
- 无 Provider
- 性能好，按需订阅
const useStore = create(set => ({
count: 0,
inc: () => set(state => ({ count: state.count + 1 }))
}));
目前在 RN 社区口碑非常好。
6. Jotai
适用场景
- 原子化状态
- 状态依赖关系复杂
特点
- 类似 Recoil
- 按原子（Atom）拆分状态
- 组合能力强
适合偏函数式、精细化状态建模的项目。
7. Recoil（逐渐边缘化）
曾经亮点
- Facebook 出品
- 原子化状态
现状
- React Native 官方投入减少
- 社区活跃度下降
- 新项目不太推荐
四、服务端状态管理（不要混用概念）
严格来说，这一类并不是“状态管理框架”，但在 RN 项目中非常重要
8. TanStack Query（React Query） ⭐⭐⭐
适用场景
- 网络请求
- 列表、分页、缓存
- 请求状态（loading / error）
核心理念
服务端状态 ≠ 客户端状态
useQuery({
queryKey: ['news'],
queryFn: fetchNews,
});
最佳实践
- 搭配 Redux / Zustand 使用
- 不要把接口数据再存进 Redux
9. SWR
特点
- 轻量
- 语义清晰
- 社区成熟
功能相对 React Query 简单一些。
五、RN 场景特有的状态方案
10. MMKV / AsyncStorage（持久化状态）
适用
- 登录态
- 配置项
- 本地缓存
通常与其他状态管理库配合使用，而不是单独使用。
六、如何选择？（实战建议）
推荐组合（非常实用）
| 场景 | 推荐方案 |
|---|---|
| 页面 UI 状态 | useState / useReducer |
| 全局业务状态 | Redux Toolkit 或 Zustand |
| 接口 / 列表数据 | TanStack Query |
| 本地持久化 | MMKV / AsyncStorage |
简单结论
-
新项目 / 中小项目： 👉 Zustand + React Query
-
中大型 / 团队协作项目： 👉 Redux Toolkit + React Query
-
不推荐：
- Context 滥用
- 所有状态全塞 Redux
七、一句话总结
React Native 没有“最好的状态管理”， 只有最适合你项目规模和团队的组合。
