手把手教你从零实现 React Native 状态管理
你有没有遇到过这样的场景？——
一个用户登录状态，要从首页传到个人中心，再传到设置页，层层props下发，中间任何一个组件都不关心这个值，却不得不接收并转发。更头疼的是，某个按钮点击后需要更新全局主题，结果整个应用“抖”了一下，所有页面都重绘了一遍。
这背后，本质上是状态管理的失控。
在 React Native 开发中，随着页面增多、交互变复杂，单纯依赖useState和 props 传递早已力不从心。虽然市面上有 Redux、MobX 等成熟方案，但它们带来的学习成本和代码冗余，对中小型项目来说往往“杀鸡用牛刀”。
那有没有一种方式，既能避开第三方库的沉重负担，又能拥有清晰的数据流和良好的可维护性？答案是：完全可以用 React 原生能力，自己搭一套轻量高效的状态管理体系。
今天，我们就来当一回“造轮子”的人，一步步构建一个属于自己的状态管理系统。不是为了替代 Redux，而是为了真正理解：状态是怎么流动的？数据是如何驱动 UI 的？
状态的本质：不只是变量，而是 UI 的心跳
在 React Native 中，“状态”听起来很抽象，其实它就是组件内部的一组变量，一旦变化，就会触发界面刷新。最熟悉的useState就是最基础的状态原语：
const [count, setCount] = useState(0);但这只是冰山一角。真正的挑战在于：当多个组件共享同一份状态时，如何保证一致性、避免混乱？
React 的设计理念是“单向数据流”：事件 → 状态变更 → 视图更新。这套机制本身非常优雅，但默认情况下，状态只能通过props一级级往下传——这就是所谓的Prop Drilling。
想象一下，你要把用户的登录信息从 App 根组件传到第五层嵌套的“消息通知”按钮里……是不是光想就头皮发麻？
这时候，我们需要一个“高速公路”，让状态可以直接“空投”到任意组件手中。这条路，就是Context API。
Context API：跨层级通信的官方解决方案
React.createContext()是 React 提供的内置工具，专门用来解决深层传参问题。它的核心思想很简单：创建一个“广播站”，谁感兴趣谁就来收听。
我们先定义一个全局状态上下文：
import React, { createContext, useContext, useState, useMemo } from 'react'; const AppStateContext = createContext();然后写一个提供者（Provider），把状态和方法打包广播出去：
export function AppProvider({ children }) { const [user, setUser] = useState(null); const [theme, setTheme] = useState('light'); const login = (userInfo) => setUser(userInfo); const logout = () => setUser(null); const toggleTheme = () => setTheme(prev => prev === 'dark' ? 'light' : 'dark'); // 使用 useMemo 避免不必要的引用变化 const value = useMemo(() => ({ user, theme, login, logout, toggleTheme }), [user, theme]); return ( <AppStateContext.Provider value={value}> {children} </AppStateContext.Provider> ); }现在，任何后代组件都可以直接“收听”这份广播：
function UserProfile() { const { user, logout } = useContext(AppStateContext); if (!user) return <Text>请先登录</Text>; return ( <View> <Text>你好，{user.name}</Text> <Button title="退出" onPress={logout} /> </View> ); }看起来已经很好用了，但还有两个隐患：
- 如果
value对象每次都重新生成（比如没用useMemo），会导致所有消费者无差别重渲染； - 状态逻辑散落在
AppProvider内部，随着功能增加会变得臃肿不堪。
怎么破？引入useReducer。
useReducer：把状态逻辑集中起来，像管理账本一样管理状态
如果你熟悉 Redux，那你会立刻爱上useReducer。它把状态更新变成了一种“记账”模式：每笔变更都通过一个动作（action）来描述，由一个纯函数（reducer）统一处理。
我们先把状态管理部分抽离出来：
// 定义初始状态 const initialState = { user: null, isAuthenticated: false, theme: 'light', }; // 创建 reducer 函数 function appReducer(state, action) { switch (action.type) { case 'LOGIN': return { ...state, user: action.payload, isAuthenticated: true, }; case 'LOGOUT': return { ...state, user: null, isAuthenticated: false, }; case 'SET_THEME': return { ...state, theme: action.payload, }; default: throw new Error(`未知的操作类型: ${action.type}`); } }然后在AppProvider中使用它：
export function AppProvider({ children }) { const [state, dispatch] = useReducer(appReducer, initialState); const value = useMemo(() => ({ // 暴露状态 user: state.user, isAuthenticated: state.isAuthenticated, theme: state.theme, // 暴露操作方法 login: (userInfo) => dispatch({ type: 'LOGIN', payload: userInfo }), logout: () => dispatch({ type: 'LOGOUT' }), setTheme: (theme) => dispatch({ type: 'SET_THEME', payload: theme }), }), [state, dispatch]); return ( <AppStateContext.Provider value={value}> {children} </AppStateContext.Provider> ); }现在，所有的状态变更都有了统一入口 ——dispatch(action)。这意味着：
- 所有更新都是可预测的：给定相同的 action，总会得到相同的新状态；
- 易于调试：你可以打印每一个
action，清楚看到“谁在什么时候改了什么”； - 便于测试：
reducer是纯函数，不依赖 UI，单元测试极其简单。
更重要的是，我们将“状态逻辑”和“UI 渲染”彻底解耦了。这是迈向良好架构的关键一步。
自定义 Hook：封装细节，暴露简洁接口
到现在为止，消费者组件仍然需要知道AppStateContext的存在，并手动调用useContext。虽然可行，但不够优雅。
我们可以进一步封装，创建一个名为useGlobalState的自定义 Hook：
export function useGlobalState() { const context = useContext(AppStateContext); if (!context) { throw new Error('useGlobalState 必须在 AppProvider 内部使用'); } return context; }从此以后，任何组件只需一句话就能拿到全局状态：
function Header() { const { theme, toggleTheme } = useGlobalState(); return ( <View style={{ backgroundColor: theme === 'dark' ? '#000' : '#fff' }}> <Button title={`${theme}模式`} onPress={toggleTheme} /> </View> ); }这种模式的优势非常明显：
- 隐藏实现细节：组件不需要关心状态是怎么来的；
- 提升复用性：同样的 Hook 可以在多个项目中迁移；
- 增强类型安全（配合 TypeScript）：
```ts
interface GlobalState {
user: User | null;
isAuthenticated: boolean;
theme: ‘light’ | ‘dark’;
login: (user: User) => void;
logout: () => void;
setTheme: (theme: ‘light’ | ‘dark’) => void;
}
export function useGlobalState(): GlobalState {
const context = useContext(AppStateContext);
if (!context) throw new Error(‘…’);
return context;
}
```
实战中的设计考量：不只是能用，更要好用
1. 拆分 Context，避免“牵一发动全身”
你可能注意到，上面的例子中我们将用户、主题等不同维度的状态放在同一个 Context 里。这样做短期内没问题，但长期来看风险很大：
当
user更新时，即使theme没变，也会导致监听theme的组件重渲染！
解决办法是：按功能域拆分 Context。
<AuthContext.Provider> <ThemeContext.Provider> <CartContext.Provider> {children} </CartContext.Provider> </ThemeContext.Provider> </AuthContext.Provider>每个 Context 只负责一类状态，互不影响。这样哪怕购物车数量频繁变动，也不会波及主题切换的性能。
2. 控制渲染范围：用React.memo+useMemo双保险
即便拆分了 Context，仍需警惕无效渲染。建议：
- 对静态或变化少的组件使用
React.memo包裹； - 在 Provider 中对
value使用useMemo记忆化；
const value = useMemo(() => ({ theme, toggleTheme }), [theme]);3. 异步操作怎么处理？
目前我们的dispatch还只能处理同步逻辑。如果登录需要调用 API 怎么办？
可以封装一个useActionsHook 来处理副作用：
export function useActions() { const { dispatch } = useGlobalState(); // 假设 dispatch 已暴露 const loginAsync = async (credentials) => { try { const userData = await api.login(credentials); dispatch({ type: 'LOGIN', payload: userData }); } catch (error) { Alert.alert('登录失败', error.message); } }; return { loginAsync }; }将来还可以在此基础上加入中间件思想，比如自动记录日志、埋点等。
4. 错误边界保护
别忘了，在大型应用中，一次状态更新崩溃可能导致整个 App 白屏。建议在AppProvider外层包裹错误边界组件，捕获并降级处理异常。
为什么我们要“造轮子”？
也许你会问：已经有 Redux Toolkit 了，为什么还要自己实现？
这个问题的答案，藏在“掌握感”三个字里。
当你只用别人的库时，你是使用者；而当你亲手实现一遍，你就成了设计者。你会明白：
- 为什么 Redux 要强调“单一状态树”？
- 为什么推荐使用
immer来简化不可变更新？ - 为什么说“action 应该是 Plain Object”？
这些最佳实践不再是一条条教条，而是你在实践中踩过坑后自然形成的认知。
更重要的是，这套基于useReducer + Context + Custom Hook的方案，足够轻量、足够灵活、足够贴近 React 官方理念。对于大多数 React Native 项目来说，它既是快速启动的理想选择，也是未来演进为更复杂架构（如集成 Redux 或 Zustand）的良好起点。
写在最后
今天我们从最基础的useState出发，一步步构建了一个完整的状态管理体系。过程中没有引入任何第三方依赖，完全依靠 React 自带的能力完成了以下目标：
✅ 实现跨组件状态共享
✅ 建立可预测的单向数据流
✅ 封装逻辑，提升可维护性
✅ 优化性能，减少无效渲染
这套方案的核心价值，不在于它多“高级”，而在于它让你真正掌握了状态流动的主动权。
下次当你面对一个新的 React Native 项目时，不妨试试从这样一个轻量级状态系统开始。你会发现，很多所谓的“复杂问题”，其实只需要回归本质，用最简单的工具，也能优雅地解决。
如果你正在做技术选型，或者想对现有项目进行状态管理重构，欢迎在评论区交流你的想法。我们一起探讨，如何写出更清晰、更健壮、更可持续的移动应用代码。
