React状态管理选型指南：Redux、Zustand、MobX、Context深度对比与实战

前端项目做到一定规模，状态管理这块迟早要面对一个绕不开的岔路口：到底该用哪套方案。我这些年接手过不少中大型项目，有从零起步的，也有半路接手别人代码的，状态管理这块踩过的坑比任何其他技术选型都多。React状态管理这件事，表面上看是选个库，实际上是在选一套数据流转的约定、一种团队协作的默契，甚至是一种长期维护的成本结构。Redux、Zustand、MobX、Context这四套方案，几乎覆盖了当下绝大多数React项目的状态管理需求，但它们各自适合的场景差异极大，选错了轻则代码越写越拧巴，重则整个项目重构。

这篇文章想做的事情很直接：把这几套方案掰开揉碎，从设计哲学、核心机制、实操落地到常见坑点，一层层讲清楚。不管你是刚接触React不久、还在纠结要不要上Redux的新手，还是已经用过其中一两套、想搞清楚什么时候该换方案的老手，都能从里面找到能直接抄作业的判断依据和代码骨架。我不会只告诉你"哪个好"，而是把每个方案为什么这么设计、在什么条件下会出问题、实际项目里怎么落地这些事讲透，让你自己能做出判断。

1. 四套方案的设计哲学与选型底层逻辑

选状态管理方案，很多人第一反应是看GitHub星数、看社区热度，这其实是最不靠谱的判断方式。真正该看的是这套方案背后的设计哲学跟你项目的实际形态匹不匹配。我见过太多项目因为"别人都在用Redux"就硬上Redux，结果一个只有三五个页面的后台管理系统，光action、reducer、saga就写了一堆文件，维护成本远超收益。所以这一章先把四套方案的底层逻辑讲清楚，后面再谈具体怎么用。

1.1 Redux：单向数据流的"重工业"体系

Redux的核心思想是单向数据流加不可变状态。整个应用的状态集中存放在一个store里，任何状态变更都必须通过dispatch一个action来触发，reducer接收到action后返回一个全新的state。这套约束看起来繁琐，但它带来的好处是状态变更完全可预测、可追溯——每一个状态是怎么变成现在这样的，你都能通过action日志还原出来。

这种设计哲学本质上是在用"约束换确定性"。在大型团队协作、多人同时改一个复杂状态树的场景下，这种确定性极其宝贵。你可以想象一个电商后台，订单状态、库存状态、用户权限状态交织在一起，如果没有一套强约束，谁在什么地方改了状态根本查不出来。Redux的action日志配合开发者工具的时间旅行调试，能把这个问题解决得很彻底。

但代价也很明显。Redux的样板代码量是四套方案里最大的，一个简单的计数器功能，action type、action creator、reducer三样东西缺一不可。虽然现在有Redux Toolkit大幅简化了写法，但它的心智负担依然存在——你得理解action、reducer、middleware、selector这一整套概念体系。对于状态逻辑简单的小项目，这套体系就是杀鸡用牛刀。

1.2 Zustand：极简主义的"钩子优先"路线

Zustand的设计哲学跟Redux几乎相反，它追求的是最小心智负担。没有action、没有reducer、没有Provider包裹，你只需要创建一个store，里面放状态和修改状态的方法，组件里用钩子取出来用就行。状态变更就是直接调用store里的方法，方法内部用set更新状态，完事。

这套方案的本质是把"状态容器"和"业务逻辑"揉在一起，用最少的抽象层数完成状态管理。它不强制你遵循任何数据流规范，你可以在store里写同步逻辑、异步逻辑、甚至直接调接口。这种自由度对中小型项目极其友好，代码量能压到Redux的几分之一。

Zustand的另一个关键设计是基于订阅的精准更新。组件只订阅自己用到的状态片段，状态变化时只有相关组件重新渲染，不需要像Context那样担心整个Provider下的组件树都跟着刷新。这个特性让它在性能敏感场景下表现相当不错，同时又不用像Redux那样手动写selector做优化。

1.3 MobX：响应式编程的"自动追踪"流派

MobX走的是完全不同的路子，它把响应式编程的思想引入了状态管理。你定义的状态用observable标记成可观察的，派生出来的值用computed标记，组件用observer包裹后，MobX会自动追踪组件用到了哪些observable，状态一变，用到它的组件自动重新渲染。整个过程你不需要手动声明依赖关系，MobX帮你做了。

这种"自动追踪"的体验用起来非常丝滑，写起来接近普通JavaScript对象的操作方式，直接赋值就能触发更新，没有action、没有dispatch。对于习惯面向对象思维、或者从Vue转过来的开发者，MobX的上手成本极低。

但MobX的"魔法"也是它的软肋。自动追踪意味着状态变更的链路是隐式的，出问题时排查起来比Redux那种显式数据流要难。而且observable、computed、action、reaction这一套装饰器或函数标记，在TypeScript类型推导上偶尔会有些别扭的地方。它适合那些状态逻辑复杂但团队对响应式思维有共识的项目。

1.4 Context：React原生的"依赖注入"机制

Context严格来说不算状态管理库，它是React内置的一套跨层级数据传递机制。你创建一个Context，用Provider把值往下传，子组件用useContext取出来。它解决的是prop drilling（属性层层透传）的问题，而不是完整的状态管理问题。

很多人把Context当状态管理用，这在一定范围内可行，但有个致命问题：Context的值一变，所有消费这个Context的组件都会重新渲染，不管它实际用没用到变化的那部分。在状态更新频繁、消费组件多的场景下，这个性能问题会非常明显。所以Context更适合存放那些变更频率低、全局共享的数据，比如主题、语言、当前登录用户信息这类。

把Context和其他三套方案并列讨论，是因为实际项目里它经常作为轻量方案的备选，也经常和其他方案组合使用。理解它的边界，才能判断什么时候该用它、什么时候该换更专业的方案。

1.5 选型决策的关键维度对照

把四套方案放在一起，从几个关键维度做个横向对照，选型时对着这张表过一遍，基本能筛掉不合适的选项。

这张表里最值得说的是"团队协作约束力"这一项。Redux之所以在大型团队里经久不衰，就是因为它用强约束把所有人的写法统一了，新人进来照着action-reducer的模式写就行，不会出现十个人十种写法的情况。而Zustand的自由度在团队规模上去之后反而可能变成负担，需要团队自己约定规范。这个维度在选型时经常被忽略，但对长期维护影响极大。

2. 核心机制拆解与关键实现细节

搞清楚设计哲学之后，得往深里看每套方案的核心机制。这一章不讲虚的，直接拆到实现层面，把每套方案的关键机制、容易出错的细节、以及实际写代码时要注意的地方讲明白。很多坑其实在机制层面就已经埋下了，理解了机制，很多问题就能提前规避。

2.1 Redux的状态更新链路与不可变原则

Redux的状态更新是一条严格的单向链路：组件dispatch action → store把action和当前state传给reducer → reducer返回新state → store通知订阅者 → 组件重新渲染。这条链路里最关键的是reducer必须是纯函数，不能有副作用，不能直接修改传入的state，必须返回一个全新的对象。

为什么强制不可变？因为Redux判断状态有没有变化，靠的是引用比较。如果你直接修改了state对象的某个属性，引用没变，Redux就认为状态没变，不会触发更新。这个坑新手几乎必踩，我见过太多人写了state.count++然后纳闷为什么页面不刷新。

用Redux Toolkit之后，它内部集成了Immer，你可以用"看起来像直接修改"的写法，Immer在底层帮你生成新的不可变对象。但这里有个细节要注意：Immer的写法虽然像直接改，但你改的其实是draft对象，返回的仍然是新引用。理解这一点，才能避免在复杂嵌套结构里写出意料之外的bug。

// Redux Toolkit 写法示例 import { createSlice } from '@reduxjs/toolkit'; const counterSlice = createSlice({ name: 'counter', initialState: { value: 0, history: [] }, reducers: { increment: (state) => { // 看起来是直接改，实际Immer生成了新对象 state.value += 1; state.history.push(state.value); }, reset: (state) => { state.value = 0; state.history = []; } } }); export const { increment, reset } = counterSlice.actions; export default counterSlice.reducer;

这段代码里state.history.push这种写法在原生Redux里是绝对禁止的，但在Redux Toolkit里是合法的，因为Immer接管了。不过要注意，如果你在reducer里做了异步操作或者调用了外部函数，Immer的追踪就会失效，所以reducer里依然要保持纯粹。

2.2 Zustand的订阅模型与选择器优化

Zustand的核心是一个极简的发布订阅模型。create函数返回一个钩子，这个钩子内部维护了一份状态和一个订阅者列表。组件调用钩子时传入一个选择器函数，Zustand会记录这个组件订阅了选择器返回的那部分值，状态更新时对比选择器返回值有没有变化，变了才触发重渲染。

这里的关键细节是选择器的返回值比较方式。Zustand默认用Object.is做浅比较，如果你选择器返回的是一个新对象，比如state => ({ a: state.a, b: state.b })，那每次状态更新这个对象都是新引用，组件就会无条件重渲染。这是Zustand最常见的性能坑。

// 错误写法：每次返回新对象，导致无谓重渲染 const { a, b } = useStore(state => ({ a: state.a, b: state.b })); // 正确写法一：分开取 const a = useStore(state => state.a); const b = useStore(state => state.b); // 正确写法二：用shallow比较 import { shallow } from 'zustand/shallow'; const { a, b } = useStore(state => ({ a: state.a, b: state.b }), shallow);

我实测下来，中小项目里分开取是最省心的做法，代码也最直观。只有在需要一次性取多个关联字段、且这些字段经常一起变化时，才考虑用shallow。另外Zustand还支持subscribeWithSelector中间件，可以更精细地控制订阅粒度，但一般项目用不到这个层级。

2.3 MobX的响应式追踪与action边界

MobX的机制核心是依赖收集。当你用observer包裹一个组件，组件渲染过程中访问了哪些observable，MobX就记录下来，建立依赖关系。observable变化时，MobX通知所有依赖它的组件重新渲染。computed值也是类似的机制，它缓存计算结果，只有依赖的observable变了才重新计算。

MobX有个重要概念叫action，用来标记"这是一次状态变更"。在严格模式下（enforceActions: 'always'），所有对observable的修改都必须在action里进行，否则会报错。这个约束的目的是把状态变更集中管理，避免散落在各处难以追踪。

import { makeAutoObservable, runInAction } from 'mobx'; class TodoStore { todos = []; filter = 'all'; constructor() { makeAutoObservable(this); } get visibleTodos() { // computed，自动缓存 if (this.filter === 'all') return this.todos; return this.todos.filter(t => t.status === this.filter); } addTodo = (text) => { // action，状态变更集中在这里 this.todos.push({ id: Date.now(), text, status: 'active' }); }; async fetchTodos() { const data = await api.getTodos(); // 异步回调里修改状态，需要runInAction包裹 runInAction(() => { this.todos = data; }); } }

这里有个容易踩的坑：异步操作里修改observable，必须用runInAction包裹，否则严格模式下会报错。因为异步回调执行时已经脱离了action的上下文，MobX无法识别这是一次合法的状态变更。这个细节在写异步逻辑时经常被忽略，报错了还一头雾水。

2.4 Context的更新传播与拆分策略

Context的机制很朴素：Provider的value变化时，所有消费这个Context的组件都会重新渲染。注意是所有，不管组件实际用没用到变化的那部分值。这个机制决定了Context的性能优化只能靠拆分——把不同更新频率的数据拆到不同的Context里。

// 拆分前：一个Context装所有，任何变化都全量刷新 const AppContext = createContext(); // 拆分后：按更新频率拆开 const UserContext = createContext(); // 登录用户，低频变化 const ThemeContext = createContext(); // 主题，低频变化 const NotificationContext = createContext(); // 通知，中频变化

拆分的粒度怎么把握？我的经验是按"更新频率"和"消费范围"两个维度来。更新频率相近、消费组件高度重叠的数据放一起，否则拆开。比如用户信息和权限信息经常一起用、都很少变，可以放一个Context；而通知列表更新频繁，单独拆出去。

还有个进阶技巧是用useMemo包裹Provider的value，避免父组件重渲染时无意中创建新value对象导致Context消费者跟着刷新。这个细节在Provider嵌套较深时特别重要。

const value = useMemo(() => ({ user, permissions }), [user, permissions]); return <UserContext.Provider value={value}>{children}</UserContext.Provider>;

2.5 四套方案的性能机制对比

性能这块，四套方案的机制差异直接决定了优化手段的不同。Redux靠selector做精准订阅，需要手动写useSelector并保证返回值的稳定性；Zustand靠选择器加浅比较，默认行为就比较精准；MobX靠自动依赖追踪，几乎不用手动优化；Context靠拆分，优化成本最高。

实际项目里，性能问题往往不是选型决定的，而是用法决定的。我见过用Redux但selector写得一塌糊涂导致全量重渲染的，也见过用Context但拆分得当、性能完全够用的。所以选型时不必过度纠结性能，先把用法搞对更重要。真正需要关注性能的场景，通常是列表渲染、高频交互、复杂表单这几类，针对这些场景做专项优化比换方案更有效。

3. 完整实操落地与代码骨架

理论讲再多，不如把代码跑起来。这一章按四套方案分别给出可直接参考的落地骨架，从项目初始化到核心功能实现，把每一步的关键点和注意事项都标出来。代码基于常见实践编写，你可以直接拿去改改用。

3.1 Redux Toolkit的工程化落地

现在上Redux基本都用Redux Toolkit，原生Redux那套写法已经很少见了。初始化一个带Redux的项目，核心是store配置和slice拆分两步。

npm install @reduxjs/toolkit react-redux

store配置这块，关键是合理拆分slice。我的经验是按业务域拆，一个业务域一个slice，不要按技术层次拆。比如用户、订单、购物车各一个slice，而不是把所有action放一个文件、所有reducer放一个文件。

// store/index.js import { configureStore } from '@reduxjs/toolkit'; import userReducer from './slices/userSlice'; import orderReducer from './slices/orderSlice'; export const store = configureStore({ reducer: { user: userReducer, order: orderReducer }, middleware: (getDefaultMiddleware) => getDefaultMiddleware({ serializableCheck: { // 如果state里有非序列化数据（如Date），需要配置忽略 ignoredActions: ['some/action'], ignoredPaths: ['some.path'] } }) });

这里有个细节值得说：serializableCheck这个中间件默认开启，会检查action和state里有没有不可序列化的数据（比如函数、Date对象、Map等）。很多人在state里存了Date对象，然后发现控制台一直报警告，就是这个原因。要么把Date转成时间戳存，要么配置忽略路径。我倾向于转成时间戳，序列化友好，调试时也方便。

异步逻辑用createAsyncThunk处理，它自动生成pending、fulfilled、rejected三个状态的action，配合extraReducers处理加载态和错误态，比手写saga简洁得多。

// slices/orderSlice.js import { createSlice, createAsyncThunk } from '@reduxjs/toolkit'; export const fetchOrders = createAsyncThunk( 'order/fetchOrders', async (userId, { rejectWithValue }) => { try { const res = await api.getOrders(userId); return res.data; } catch (err) { return rejectWithValue(err.message); } } ); const orderSlice = createSlice({ name: 'order', initialState: { list: [], loading: false, error: null }, reducers: {}, extraReducers: (builder) => { builder .addCase(fetchOrders.pending, (state) => { state.loading = true; state.error = null; }) .addCase(fetchOrders.fulfilled, (state, action) => { state.loading = false; state.list = action.payload; }) .addCase(fetchOrders.rejected, (state, action) => { state.loading = false; state.error = action.payload; }); } });

组件里用useSelector取状态时，一定要保证selector返回值的稳定性。取单个字段没问题，取多个字段要么分开取，要么用shallowEqual做比较。

import { useSelector, useDispatch } from 'react-redux'; import { shallowEqual } from 'react-redux'; // 取单个字段，安全 const list = useSelector(state => state.order.list); // 取多个字段，用shallowEqual const { loading, error } = useSelector( state => ({ loading: state.order.loading, error: state.order.error }), shallowEqual );

3.2 Zustand的轻量落地与模块拆分

Zustand的落地极其简单，装个包，写个store，完事。但项目规模上去之后，store怎么拆分、怎么组织，是需要提前规划的。

npm install zustand

单store的写法适合小项目，所有状态和方法放一个文件里。但状态一多，这个文件会膨胀得很快，所以中大型项目建议按业务域拆成多个store。

// stores/userStore.js import { create } from 'zustand'; export const useUserStore = create((set, get) => ({ user: null, token: null, login: async (credentials) => { const res = await api.login(credentials); set({ user: res.user, token: res.token }); }, logout: () => set({ user: null, token: null }), // get()可以拿到当前完整状态，用于跨字段逻辑 isLoggedIn: () => !!get().token }));

这里有个实用技巧：set支持函数式更新，当你需要基于当前状态计算新状态时，用函数式写法更安全。

// 安全：基于当前状态更新 increment: () => set(state => ({ count: state.count + 1 })), // 危险：直接引用外部变量，可能拿到过期值 increment: () => set({ count: someExternalValue + 1 })

跨store的联动怎么处理？Zustand官方推荐的做法是在一个store里调用另一个store的方法。比如用户登出时清空订单store，可以在userStore的logout里直接调orderStore的reset方法。这种写法虽然耦合，但比引入额外的协调层简单直接，中小项目完全够用。

import { useOrderStore } from './orderStore'; logout: () => { set({ user: null, token: null }); useOrderStore.getState().reset(); // 跨store调用 }

持久化这块，Zustand有persist中间件，几行配置就能把指定状态存到localStorage。但要注意，不是所有状态都该持久化，像loading、error这类临时状态存了反而会出问题，用partialize过滤掉。

import { persist } from 'zustand/middleware'; export const useUserStore = create( persist( (set) => ({ user: null, token: null, setUser: (user) => set({ user }) }), { name: 'user-storage', partialize: (state) => ({ user: state.user, token: state.token }) } ) );

3.3 MobX的响应式落地与严格模式配置

MobX的落地关键是store的类设计和严格模式配置。现在主流写法是用makeAutoObservable，它会自动把普通属性标记为observable、getter标记为computed、方法标记为action，省去手动标记的麻烦。

npm install mobx mobx-react-lite

store设计上，MobX天然适合面向对象的组织方式，一个业务域一个类，类里封装状态、计算属性和方法。

// stores/CartStore.js import { makeAutoObservable, runInAction } from 'mobx'; class CartStore { items = []; loading = false; constructor() { makeAutoObservable(this); } get totalPrice() { return this.items.reduce((sum, item) => sum + item.price * item.quantity, 0); } get itemCount() { return this.items.reduce((sum, item) => sum + item.quantity, 0); } addItem = (product) => { const existing = this.items.find(i => i.id === product.id); if (existing) { existing.quantity += 1; } else { this.items.push({ ...product, quantity: 1 }); } }; async loadCart() { this.loading = true; try { const data = await api.getCart(); runInAction(() => { this.items = data; this.loading = false; }); } catch (err) { runInAction(() => { this.loading = false; }); } } } export const cartStore = new CartStore();

严格模式配置在应用入口做，enforceActions: 'always'能强制所有状态变更走action，配合computedRequiresReaction和reactionRequiresObservable，能在开发阶段提前暴露很多不规范用法。

import { configure } from 'mobx'; configure({ enforceActions: 'always', computedRequiresReaction: true, reactionRequiresObservable: true, disableErrorBoundaries: false });

组件里用observer包裹，才能响应observable变化。这里有个容易忘的点：只有真正读取了observable的组件才需要observer，如果组件只是接收props渲染，不需要包。但实际项目里为了省心，业务组件统一包observer也没问题，性能开销可以忽略。

import { observer } from 'mobx-react-lite'; import { cartStore } from '../stores/CartStore'; const CartBadge = observer(() => { return <span>{cartStore.itemCount}</span>; });

3.4 Context的分层设计与组合使用

Context的落地核心是分层设计。我一般把Context分成三层：全局配置层（主题、语言）、用户会话层（登录信息、权限）、业务临时层（弹窗、通知）。层与层之间不交叉，各自独立Provider。

// contexts/ThemeContext.js import { createContext, useContext, useState, useMemo } from 'react'; const ThemeContext = createContext(null); export function ThemeProvider({ children }) { const [theme, setTheme] = useState('light'); const value = useMemo(() => ({ theme, setTheme }), [theme]); return <ThemeContext.Provider value={value}>{children}</ThemeContext.Provider>; } export function useTheme() { const ctx = useContext(ThemeContext); if (!ctx) throw new Error('useTheme must be used within ThemeProvider'); return ctx; }

这里有个细节：自定义钩子里加个判空抛错，能在忘记包Provider时快速定位问题，比运行时莫名其妙的undefined报错友好得多。这个习惯我强烈建议养成。

Context和其他方案组合使用也很常见。比如用Zustand管业务状态，用Context管主题和国际化，各司其职。这种组合的关键是划清边界：变更频繁的、需要精细订阅的走Zustand，变更低频的、纯配置类的走Context。

// 组合示例：Zustand管业务，Context管主题 function App() { return ( <ThemeProvider> <AuthProvider> <Router> <Routes /> </Router> </AuthProvider> </ThemeProvider> ); }

3.5 迁移路径与渐进式改造策略

实际项目里经常遇到的是迁移场景，比如从Context迁到Zustand，或者从Redux迁到Zustand。我的建议是渐进式改造，不要一次性全量替换，风险太大。

迁移的基本策略是"新功能用新方案，老功能逐步替换"。先在项目里引入新方案的store，新写的模块直接用新方案，老模块保持不动。等新方案在项目里跑稳了，再按模块逐个迁移老代码。每迁一个模块，跑一遍回归测试，确保没问题再迁下一个。

从Context迁到Zustand的典型路径：先把Context里的状态和方法原样搬到Zustand store里，然后把消费Context的组件改成用Zustand钩子，最后删掉Context。这个过程中两套方案可以共存，不会冲突。

从Redux迁到Zustand要稍微复杂点，因为Redux的action-reducer模式跟Zustand的直接调用模式差异较大。我的做法是先把reducer里的逻辑改写成store里的方法，保持状态结构不变，然后逐个替换useSelector和dispatch调用。异步逻辑从thunk或saga改成store里的async方法。这个过程建议按slice逐个迁，迁完一个slice验证一个。

4. 常见问题排查与避坑实录

这一章是我这些年踩坑踩出来的经验汇总，很多问题在官方文档里找不到，但实际项目里几乎必然会遇到。按方案分类整理，配上排查思路和解决方法，遇到问题时可以直接对照查。

4.1 Redux的高频问题与排查

Redux最常见的问题集中在"状态更新了但组件没刷新"和"组件刷新过于频繁"这两类。前者多半是不可变原则被破坏，后者多半是selector写得有问题。

状态不更新的排查顺序：先确认reducer有没有返回新对象（用Redux Toolkit的话检查是不是在reducer里做了异步操作导致Immer失效），再确认组件用的selector路径对不对，最后确认store有没有正确挂到Provider上。这三步能解决九成以上的不更新问题。

组件过度刷新的排查：打开React DevTools的Profiler，看是哪个组件在刷、为什么刷。如果是用了useSelector返回新对象导致的，改成分开取或用shallowEqual。如果是父组件刷新带动的，检查父组件的selector。

还有个隐蔽的坑：在组件渲染过程中dispatch action。这会导致无限循环渲染，因为dispatch触发状态更新，状态更新又触发渲染，渲染又dispatch。排查时看控制台有没有"Maximum update depth exceeded"的报错，有的话重点查useEffect依赖和渲染期间的dispatch调用。

4.2 Zustand的订阅陷阱与状态同步

Zustand最常见的问题是选择器返回新对象导致的无谓重渲染，前面讲过，这里补充一个更隐蔽的场景：在store方法里读取状态时用了过期的闭包值。

// 错误：闭包捕获了创建时的count值 const useStore = create((set) => ({ count: 0, doubleAfterDelay: () => { setTimeout(() => { set({ count: this.count * 2 }); // this.count是旧值 }, 1000); } })); // 正确：用get()拿最新值 const useStore = create((set, get) => ({ count: 0, doubleAfterDelay: () => { setTimeout(() => { set({ count: get().count * 2 }); }, 1000); } }));

这个坑在异步逻辑里特别常见，因为setTimeout、Promise回调执行时，闭包里的状态值早就过期了。养成用get()拿最新值的习惯，能避免大量诡异bug。

另一个常见问题是多个组件同时修改同一状态导致的竞态。比如两个组件都在加载时设置loading为true，一个先完成设成false，另一个还在加载但loading已经变false了。这种问题Zustand本身不解决，需要在业务层用请求计数或请求ID来管理。我的做法是在store里维护一个pending请求的计数，计数归零才设loading为false。

4.3 MobX的响应式失效与严格模式报错

MobX最让人头疼的是"响应式失效"——明明状态变了，组件就是不刷新。排查这类问题，先确认组件有没有用observer包裹，这是最常见的原因。其次确认读取observable的时机，如果在observer组件外部读取（比如在普通函数里读取后传进去），依赖收集不会生效。

严格模式下的报错也是高频问题，典型报错是"Side effects like changing state are not allowed at this point"。这个报错的意思是你在action外部修改了observable。解决方法有两种：把修改逻辑包进action，或者用runInAction包裹。异步回调里的修改必须用后者。

还有个容易忽略的点：数组和对象的深层修改。MobX对observable数组的push、splice等操作是能追踪的，但如果你把observable数组转成了普通数组再操作，追踪就断了。比如[...store.items].push(x)这种写法，操作的是新数组，store里的原数组没变，自然不会触发更新。

4.4 Context的性能问题与拆分实践

Context的性能问题排查，核心是搞清楚"谁在刷新、为什么刷新"。用React DevTools的Profiler录制一段交互，看哪些组件在不必要地重渲染。如果发现某个Context的消费者在值没变时也刷新，检查Provider的value是不是每次渲染都创建了新对象。

拆分Context的实操建议：先按业务域粗拆，跑一段时间看性能表现，有问题再细拆。不要一上来就拆得特别细，Provider嵌套太深反而增加维护成本。我一般控制在三层以内，超过三层就考虑用Zustand之类的方案替代。

还有个实用技巧：把Context的读取封装成自定义钩子，钩子内部可以做缓存、可以做默认值处理、可以加判空逻辑。这样消费方用起来干净，将来要换实现也只改钩子一处。

4.5 跨方案共性问题与通用排查思路

不管用哪套方案，有些问题是共通的。比如"状态更新了但UI没变"，排查思路都是先确认状态真的变了（用开发者工具看），再确认组件订阅了这部分状态，最后确认更新触发了渲染。这个三步排查法适用于所有方案。

再比如"内存泄漏"，多半是组件卸载后还有异步回调在修改状态。React 18之后虽然对卸载后setState的警告放宽了，但泄漏本身还在。解决方法是在useEffect的清理函数里取消订阅、取消请求、清除定时器。各方案的取消方式不同：Redux的thunk可以用AbortController，Zustand的订阅用返回的取消函数，MobX的reaction用dispose，Context没有内置取消机制需要自己封装。

5. 选型决策的实战判断与团队落地建议

前面把四套方案的机制、实操、坑点都过了一遍，这一章回到最初的问题：到底怎么选。我给一套实战判断框架，不是让你照搬，而是帮你理清决策逻辑，结合自己项目的情况做判断。

5.1 按项目规模与团队情况做判断

项目规模是最直观的判断维度，但不是唯一维度。我一般从三个角度综合看：状态复杂度、团队规模、项目生命周期。

状态复杂度看的是跨组件共享的状态有多少、状态之间的依赖关系有多复杂。如果只是主题、用户信息这类少量全局状态，Context完全够用。如果涉及多模块数据联动、复杂表单、实时数据流，就得上专业方案。

团队规模决定约束力的需求。三五个人的小团队，Zustand的自由度是优势，大家约定好规范就行。十几人以上的团队，Redux的强约束能显著降低协作成本，新人上手有明确的模式可循。

项目生命周期影响长期维护成本。短期项目、验证性项目，选上手快的Zustand或Context。长期维护的核心项目，选生态成熟、模式稳定的Redux或MobX，虽然前期投入大，但长期看更稳。

5.2 从零搭建与存量改造的不同策略

从零搭建的项目，选型自由度大，按上面的框架选就行。但要注意一点：不要过度设计。我见过太多项目一开始就上Redux全家桶，结果实际用到的功能不到三成，剩下的都是维护负担。从简到繁，状态管理需求增长了再升级方案，比一开始就上重方案更合理。

存量改造的项目，核心原则是渐进式、可回滚。先在局部引入新方案验证，跑稳了再扩大范围。改造过程中新旧方案共存是常态，不要追求一次性替换干净。每完成一个模块的迁移，做好回归测试，确保业务不受影响。

改造时还有个细节：状态结构的映射。老方案的状态结构往往跟业务耦合较深，迁移时不要原样搬，借机梳理一遍，把不该放全局的状态下沉到组件本地，把该合并的合并，该拆分的拆分。这个过程本身就能优化不少性能问题。

5.3 混合使用的边界划分与协作规范

实际项目里，单一方案往往不够用，混合使用是常态。关键是划清边界，避免状态散落各处、职责不清。

我的划分原则是：全局配置类走Context，业务状态走Zustand或Redux，组件内部状态走useState。全局配置类包括主题、语言、登录用户这类变更低频、全局共享的数据；业务状态包括列表数据、表单数据、业务流程状态；组件内部状态就是那些只在一个组件里用的临时状态。

混合使用时，团队要约定好规范：状态放哪一层、命名怎么定、跨层怎么通信。这些规范不写下来，团队大了必然乱。我一般会在项目文档里维护一份状态管理约定，新成员进来先看这个。

5.4 长期维护视角下的方案演进

状态管理方案不是选完就一劳永逸的，项目在演进，方案也得跟着调整。我经历过从Context起步、业务增长后引入Zustand、最后核心模块迁到Redux Toolkit的完整过程。每次演进都是因为现有方案在某个维度上撑不住了，而不是因为"新方案更流行"。

判断要不要换方案，看几个信号：现有方案的样板代码占比越来越高、性能问题频繁出现且优化成本高、团队新人上手现有方案的学习成本明显增加、现有方案的模式跟业务形态越来越不匹配。出现这些信号，就该认真评估换方案了。

换方案的成本要提前算清楚，包括代码改造量、测试回归量、团队学习成本、过渡期的维护成本。这些成本加起来往往比想象的高，所以能通过优化用法解决的问题，优先优化用法，实在撑不住了再换方案。

5.5 一套可直接套用的选型检查清单

最后给一份选型检查清单，新项目选型或老项目评估时，逐条过一遍，基本能得出靠谱的结论。

• 项目里跨组件共享的状态有多少？少于5个用Context，5到20个考虑Zustand，20个以上认真评估Redux或MobX。
• 状态之间的依赖关系复杂吗？有大量派生状态、联动更新的，MobX的computed或Redux的selector更合适。
• 团队有多少人参与前端开发？超过8人建议上强约束方案。
• 项目预期维护多久？超过两年的核心项目优先考虑生态成熟度。
• 团队对哪套方案有经验积累？有经验优先，学习成本也是成本。
• 有没有性能敏感场景？高频更新、大列表渲染的场景，优先Zustand或MobX。
• 需不需要时间旅行调试、状态快照？需要的话Redux是唯一选择。
• 异步逻辑多不多？多的话优先内置异步支持的Zustand或MobX。

这套清单不是打分制，而是帮你把决策因素摆出来，逐条对照自己项目的情况，答案往往就清晰了。我个人的经验是，大部分中小项目用Zustand加Context的组合就能覆盖得很好，真正需要Redux的场景比想象中少。选型时克制一点，别被"最佳实践"绑架，适合自己项目的才是最好的。

我在实际项目里反复验证下来，状态管理这块最忌讳的就是"为了用而用"。工具是服务于业务的，业务简单就用简单的工具，业务复杂了再升级。踩过几次选型过重的坑之后，我现在给新项目的默认建议都是：先用Context和useState把能做的做了，确实遇到瓶颈了，再引入Zustand，Redux留给那些真正需要强约束和可追溯性的大型项目。这个顺序反过来，往往就是给自己找麻烦。