1. 为什么Zustand正在取代Redux前端状态管理领域最近两年出现了一个明显的趋势越来越多的开发者开始从Redux转向Zustand。作为一个长期使用Redux的老兵我第一次接触Zustand时也带着怀疑——这个不到1kb的库真能解决复杂的状态管理问题但实际使用后发现它不仅解决了Redux的痛点还带来了更符合现代React开发的体验。Redux的核心问题在于样板代码过多。一个简单的计数器功能就需要定义action types、action creators、reducer还要用connect或useSelector/useDispatch来连接组件。而Zustand直接让你定义一个store在组件中使用就像调用一个hook那么简单。这种开发体验的差异就像从class组件迁移到hooks一样令人愉悦。2. Zustand核心设计解析2.1 极简的API设计Zustand的API精简到令人惊讶的程度主要就三个核心方法import create from zustand const useStore create(set ({ count: 0, increment: () set(state ({ count: state.count 1 })), decrement: () set(state ({ count: state.count - 1 })) }))这个简单的store包含了状态和修改状态的方法在组件中使用时function Counter() { const { count, increment } useStore() return button onClick{increment}{count}/button }2.2 基于Hook的消费方式与Redux需要connect或useSelector不同Zustand store本身就是个hook。这意味着自动处理组件订阅和取消订阅完美融入React的hooks生态不需要Provider包裹整个应用2.3 细粒度更新控制Zustand默认使用严格相等()来比较状态变化这带来了极佳的性能// 只订阅count的变化 const count useStore(state state.count)相比之下Redux的useSelector需要手动处理记忆化(memoization)来避免不必要的渲染。3. 从Redux迁移到Zustand的实战指南3.1 状态结构的转换Redux的单一store通常被拆分为多个reducer而Zustand更推荐模块化的stores。例如将用户数据和UI状态分开// userStore.js export const useUserStore create(set ({ user: null, login: (user) set({ user }), logout: () set({ user: null }) })) // uiStore.js export const useUiStore create(set ({ theme: light, toggleTheme: () set(state ({ theme: state.theme light ? dark : light })) }))3.2 中间件生态对比Redux强大的中间件系统是其优势之一Zustand也提供了类似的机制import { devtools, persist } from zustand/middleware const useStore create( devtools( persist( set ({ // ...store定义 }), { name: my-store } ) ) )常用中间件包括devtoolsRedux DevTools集成persist本地存储持久化immer简化不可变更新3.3 异步处理模式处理异步操作时Zustand比Redux简洁得多const useStore create(set ({ posts: [], loading: false, fetchPosts: async () { set({ loading: true }) const posts await fetch(/api/posts).then(res res.json()) set({ posts, loading: false }) } }))不需要redux-thunk这样的中间件直接在store中写async/await即可。4. Zustand高级技巧与性能优化4.1 状态切片选择对于大型store精确选择需要的状态片段至关重要// 不好的做法 - 获取整个store const { user, posts, comments, ... } useStore() // 推荐做法 - 只选择需要的字段 const user useStore(state state.user) const posts useStore(state state.posts)4.2 不可变更新模式虽然Zustand不强制不可变性但保持这个习惯能让代码更可预测// 使用展开运算符 set(state ({ ...state, count: state.count 1 })) // 或者使用immer中间件 import { immer } from zustand/middleware/immer const useStore create( immer((set) ({ user: { name: John, age: 30 }, updateName: (name) set(state { state.user.name name }) })) )4.3 跨store通信当需要多个store交互时可以在创建时注入其他storeconst useAuthStore create(set ({ user: null, login: () set({ user: { name: John } }) })) const useCartStore create((set, get) ({ items: [], checkout: () { const user get().user // 从authStore获取 if (!user) throw new Error(Not logged in) // 结账逻辑 } }))5. 常见问题与解决方案5.1 Zustand vs Redux性能对比在大多数场景下Zustand的性能优于Redux特别是在初始加载时间更小的包体积组件更新效率细粒度订阅内存使用更简单的内部实现但在超大型应用数千个action类型中Redux的devtools可能更有优势。5.2 何时该选择Redux虽然Zustand很优秀但Redux仍然适用于已有大型Redux代码库的项目需要强大时间旅行调试的复杂应用团队已经高度熟悉Redux模式5.3 Zustand的局限性目前Zustand的社区生态还不如Redux丰富特别是在学习资源数量中间件选择TypeScript类型定义完整性6. 实战案例电商购物车实现让我们用一个完整的购物车示例展示Zustand的能力const useCartStore create((set, get) ({ items: [], total: 0, addItem: (product) { const { items } get() const existingItem items.find(item item.id product.id) if (existingItem) { set({ items: items.map(item item.id product.id ? { ...item, quantity: item.quantity 1 } : item ) }) } else { set({ items: [...items, { ...product, quantity: 1 }] }) } // 计算总价 set({ total: calculateTotal(get().items) }) }, removeItem: (productId) { set({ items: get().items.filter(item item.id ! productId), total: calculateTotal(get().items) }) } })) function calculateTotal(items) { return items.reduce((sum, item) sum (item.price * item.quantity), 0) }在组件中使用function Cart() { const { items, total, addItem, removeItem } useCartStore() return ( div h2购物车总价: {total}/h2 ul {items.map(item ( li key{item.id} {item.name} x {item.quantity} button onClick{() removeItem(item.id)}移除/button /li ))} /ul /div ) } function Product({ product }) { const { addItem } useCartStore() return ( div h3{product.name}/h3 button onClick{() addItem(product)}加入购物车/button /div ) }这个实现展示了Zustand的几个优势逻辑与UI完全分离派生状态total自动计算无需任何样板代码类型安全配合TypeScript7. TypeScript集成实践Zustand对TypeScript的支持非常出色。下面是类型化的store定义interface CartState { items: Array{ id: string name: string price: number quantity: number } total: number addItem: (product: OmitCartState[items][0], quantity) void removeItem: (id: string) void } const useCartStore createCartState((set, get) ({ items: [], total: 0, addItem: (product) { /* 实现 */ }, removeItem: (id) { /* 实现 */ } }))在组件中使用时可以获得完整的类型提示和检查const { items } useCartStore() // items被正确推断为CartState[items]8. 测试策略测试Zustand store与测试React组件解耦非常直观import { act } from testing-library/react import { create } from zustand test(should add items to cart, () { const useTestStore create(set ({ items: [], addItem: (item) set(state ({ items: [...state.items, item] })) })) let store act(() { store useTestStore.getState() }) act(() { store.addItem({ id: 1, name: Product }) }) expect(useTestStore.getState().items).toEqual([ { id: 1, name: Product } ]) })关键测试要点测试纯JavaScript函数不依赖React使用getState()获取当前状态用act包裹状态更新9. 与React Context的性能对比许多开发者用Context API做状态管理但性能上存在严重问题// 不推荐的Context用法 const AppContext createContext() function AppProvider({ children }) { const [state, setState] useState({ user: null, theme: light, cart: [] // ...更多状态 }) return ( AppContext.Provider value{{ state, setState }} {children} /AppContext.Provider ) }这种模式的问题在于任何状态变化都会导致所有消费者重新渲染需要手动记忆化(memoization)随着应用增长性能急剧下降Zustand的解决方案更优雅自动处理订阅/取消订阅细粒度更新无需Provider包裹10. 状态持久化方案对于需要持久化的状态如用户偏好Zustand的persist中间件是理想选择import { persist } from zustand/middleware const useSettingsStore create( persist( set ({ theme: light, toggleTheme: () set(state ({ theme: state.theme light ? dark : light })) }), { name: settings-storage, // localStorage的key getStorage: () localStorage, // 也可以是sessionStorage } ) )这个store会在初始化时自动从localStorage加载并在每次变化时自动保存。 
长河君 · 2026/10/28 16:25:43 · 阅读 1.2k Zustand vs Redux：现代React状态管理对比与迁移指南
1. 为什么Zustand正在取代Redux前端状态管理领域最近两年出现了一个明显的趋势越来越多的开发者开始从Redux转向Zustand。作为一个长期使用Redux的老兵我第一次接触Zustand时也带着怀疑——这个不到1kb的库真能解决复杂的状态管理问题但实际使用后发现它不仅解决了Redux的痛点还带来了更符合现代React开发的体验。Redux的核心问题在于样板代码过多。一个简单的计数器功能就需要定义action types、action creators、reducer还要用connect或useSelector/useDispatch来连接组件。而Zustand直接让你定义一个store在组件中使用就像调用一个hook那么简单。这种开发体验的差异就像从class组件迁移到hooks一样令人愉悦。2. Zustand核心设计解析2.1 极简的API设计Zustand的API精简到令人惊讶的程度主要就三个核心方法import create from zustand const useStore create(set ({ count: 0, increment: () set(state ({ count: state.count 1 })), decrement: () set(state ({ count: state.count - 1 })) }))这个简单的store包含了状态和修改状态的方法在组件中使用时function Counter() { const { count, increment } useStore() return button onClick{increment}{count}/button }2.2 基于Hook的消费方式与Redux需要connect或useSelector不同Zustand store本身就是个hook。这意味着自动处理组件订阅和取消订阅完美融入React的hooks生态不需要Provider包裹整个应用2.3 细粒度更新控制Zustand默认使用严格相等()来比较状态变化这带来了极佳的性能// 只订阅count的变化 const count useStore(state state.count)相比之下Redux的useSelector需要手动处理记忆化(memoization)来避免不必要的渲染。3. 从Redux迁移到Zustand的实战指南3.1 状态结构的转换Redux的单一store通常被拆分为多个reducer而Zustand更推荐模块化的stores。例如将用户数据和UI状态分开// userStore.js export const useUserStore create(set ({ user: null, login: (user) set({ user }), logout: () set({ user: null }) })) // uiStore.js export const useUiStore create(set ({ theme: light, toggleTheme: () set(state ({ theme: state.theme light ? dark : light })) }))3.2 中间件生态对比Redux强大的中间件系统是其优势之一Zustand也提供了类似的机制import { devtools, persist } from zustand/middleware const useStore create( devtools( persist( set ({ // ...store定义 }), { name: my-store } ) ) )常用中间件包括devtoolsRedux DevTools集成persist本地存储持久化immer简化不可变更新3.3 异步处理模式处理异步操作时Zustand比Redux简洁得多const useStore create(set ({ posts: [], loading: false, fetchPosts: async () { set({ loading: true }) const posts await fetch(/api/posts).then(res res.json()) set({ posts, loading: false }) } }))不需要redux-thunk这样的中间件直接在store中写async/await即可。4. Zustand高级技巧与性能优化4.1 状态切片选择对于大型store精确选择需要的状态片段至关重要// 不好的做法 - 获取整个store const { user, posts, comments, ... } useStore() // 推荐做法 - 只选择需要的字段 const user useStore(state state.user) const posts useStore(state state.posts)4.2 不可变更新模式虽然Zustand不强制不可变性但保持这个习惯能让代码更可预测// 使用展开运算符 set(state ({ ...state, count: state.count 1 })) // 或者使用immer中间件 import { immer } from zustand/middleware/immer const useStore create( immer((set) ({ user: { name: John, age: 30 }, updateName: (name) set(state { state.user.name name }) })) )4.3 跨store通信当需要多个store交互时可以在创建时注入其他storeconst useAuthStore create(set ({ user: null, login: () set({ user: { name: John } }) })) const useCartStore create((set, get) ({ items: [], checkout: () { const user get().user // 从authStore获取 if (!user) throw new Error(Not logged in) // 结账逻辑 } }))5. 常见问题与解决方案5.1 Zustand vs Redux性能对比在大多数场景下Zustand的性能优于Redux特别是在初始加载时间更小的包体积组件更新效率细粒度订阅内存使用更简单的内部实现但在超大型应用数千个action类型中Redux的devtools可能更有优势。5.2 何时该选择Redux虽然Zustand很优秀但Redux仍然适用于已有大型Redux代码库的项目需要强大时间旅行调试的复杂应用团队已经高度熟悉Redux模式5.3 Zustand的局限性目前Zustand的社区生态还不如Redux丰富特别是在学习资源数量中间件选择TypeScript类型定义完整性6. 实战案例电商购物车实现让我们用一个完整的购物车示例展示Zustand的能力const useCartStore create((set, get) ({ items: [], total: 0, addItem: (product) { const { items } get() const existingItem items.find(item item.id product.id) if (existingItem) { set({ items: items.map(item item.id product.id ? { ...item, quantity: item.quantity 1 } : item ) }) } else { set({ items: [...items, { ...product, quantity: 1 }] }) } // 计算总价 set({ total: calculateTotal(get().items) }) }, removeItem: (productId) { set({ items: get().items.filter(item item.id ! productId), total: calculateTotal(get().items) }) } })) function calculateTotal(items) { return items.reduce((sum, item) sum (item.price * item.quantity), 0) }在组件中使用function Cart() { const { items, total, addItem, removeItem } useCartStore() return ( div h2购物车总价: {total}/h2 ul {items.map(item ( li key{item.id} {item.name} x {item.quantity} button onClick{() removeItem(item.id)}移除/button /li ))} /ul /div ) } function Product({ product }) { const { addItem } useCartStore() return ( div h3{product.name}/h3 button onClick{() addItem(product)}加入购物车/button /div ) }这个实现展示了Zustand的几个优势逻辑与UI完全分离派生状态total自动计算无需任何样板代码类型安全配合TypeScript7. TypeScript集成实践Zustand对TypeScript的支持非常出色。下面是类型化的store定义interface CartState { items: Array{ id: string name: string price: number quantity: number } total: number addItem: (product: OmitCartState[items][0], quantity) void removeItem: (id: string) void } const useCartStore createCartState((set, get) ({ items: [], total: 0, addItem: (product) { /* 实现 */ }, removeItem: (id) { /* 实现 */ } }))在组件中使用时可以获得完整的类型提示和检查const { items } useCartStore() // items被正确推断为CartState[items]8. 测试策略测试Zustand store与测试React组件解耦非常直观import { act } from testing-library/react import { create } from zustand test(should add items to cart, () { const useTestStore create(set ({ items: [], addItem: (item) set(state ({ items: [...state.items, item] })) })) let store act(() { store useTestStore.getState() }) act(() { store.addItem({ id: 1, name: Product }) }) expect(useTestStore.getState().items).toEqual([ { id: 1, name: Product } ]) })关键测试要点测试纯JavaScript函数不依赖React使用getState()获取当前状态用act包裹状态更新9. 与React Context的性能对比许多开发者用Context API做状态管理但性能上存在严重问题// 不推荐的Context用法 const AppContext createContext() function AppProvider({ children }) { const [state, setState] useState({ user: null, theme: light, cart: [] // ...更多状态 }) return ( AppContext.Provider value{{ state, setState }} {children} /AppContext.Provider ) }这种模式的问题在于任何状态变化都会导致所有消费者重新渲染需要手动记忆化(memoization)随着应用增长性能急剧下降Zustand的解决方案更优雅自动处理订阅/取消订阅细粒度更新无需Provider包裹10. 状态持久化方案对于需要持久化的状态如用户偏好Zustand的persist中间件是理想选择import { persist } from zustand/middleware const useSettingsStore create( persist( set ({ theme: light, toggleTheme: () set(state ({ theme: state.theme light ? dark : light })) }), { name: settings-storage, // localStorage的key getStorage: () localStorage, // 也可以是sessionStorage } ) )这个store会在初始化时自动从localStorage加载并在每次变化时自动保存。