前端状态管理选 Redux 还是 Zustand？有什么区别

**结论先行：新项目、中小型应用、只想解决跨组件共享状态，选 Zustand；大型团队协作、需要严格可预测的数据流、时间旅行调试或已深度绑定 Redux 生态，选 Redux Toolkit（RTK）。两者性能差距可以忽略，真正的差别是"约束强度"和"样板代码量"。**

Redux 和 Zustand 的核心区别是什么？

结论：Redux 是"框架式"方案，用 action、reducer、dispatch 三件套强制约定数据流向；Zustand 是"库式"方案，一个 create 就能定义 store 和 action，不需要 Provider 包裹。

代码量差异最直观。Redux Toolkit 2.x（2023 年 12 月发布，依赖 Redux 5.0）需要三步：切片、配置 store、在根组件挂 <Provider store={store}>：

// counterSlice.js
import { createSlice } from '@reduxjs/toolkit'
const counter = createSlice({
  name: 'counter',
  initialState: { value: 0 },
  reducers: { inc: (s) => { s.value += 1 } }   // 内部用 Immer，可直接"改"state
})
export const { inc } = counter.actions
export default counter.reducer
// store.js
import { configureStore } from '@reduxjs/toolkit'
export const store = configureStore({ reducer: { counter: counter.reducer } })

Zustand 5.0（2024 年 10 月发布，要求 React 18+）同样功能只要一段：

import { create } from 'zustand'
export const useCounter = create((set) => ({
  value: 0,
  inc: () => set((s) => ({ value: s.value + 1 }))
}))
// 任意组件里：const value = useCounter((s) => s.value)

注意 Zustand 5 取消了默认导出，必须写 import { create } from 'zustand'，这是从 4.x 升级时最常见的报错来源。

两者在重渲染性能上有什么差别？

结论：都支持精确订阅，性能上不存在"谁一定更快"，但 Zustand 默认更省心。

Zustand 基于 React 18 正式提供的 useSyncExternalStore 订阅外部 store，不依赖 Context，所以不会有"Provider 值变化导致整棵子树重渲染"的问题。它的 selector 用 Object.is 比较结果，只在选中值变化时触发重渲染。

Redux 的 useSelector 默认同样是引用比较（===），一旦 selector 返回新对象或新数组，每次 dispatch 都会重渲染，必须补 shallowEqual 或 createSelector 做记忆化：

import { shallowEqual, useSelector } from 'react-redux'
const { a, b } = useSelector((s) => ({ a: s.a, b: s.b }), shallowEqual)

Zustand 5 里如果 selector 返回新对象而不加 useShallow（来自 zustand/react/shallow），会直接抛出无限循环警告，这是 v5 的一个破坏性变更。

体积上，Zustand 约 1.2 kB（min+gzip），Redux Toolkit 约 13 kB 加上 react-redux 约 5 kB，合计逼近 18 kB。差值对现代网络环境不致命，但在移动端首屏仍有意义。

什么场景必须用 Redux Toolkit？

结论：需要"约束"和"可审计"的场景，Redux 的代价才划算。

具体是这四类：一是 10 人以上团队并行开发，action 类型和 reducer 的强约束能避免状态被随意修改；二是需要 Redux DevTools 的时间旅行、action 回放和状态快照，排查线上复杂状态问题；三是异步流程复杂，需要 RTK Query 统一管理服务端缓存、请求去重、轮询与失效；四是已有 redux-saga、redux-observable、redux-persist 等中间件资产。

Zustand 也能加 devtools、persist、immer 中间件，但调试体验和生态深度不及 Redux。

从 Redux 迁到 Zustand 要改什么？

结论：迁移成本主要在 selector 写法，业务逻辑几乎不用动。

步骤一，把每个 slice 的 initialState 和 reducers 直接搬进 create((set) => ({...}))，state.value 改写成 s.value。步骤二，删掉 <Provider> 和 configureStore。步骤三，全局替换调用方式：useSelector((s) => s.counter.value) → useCounter((s) => s.value)，dispatch(inc()) → inc()。步骤四，异步 createAsyncThunk 改写成 store 内的 async 方法，直接 await 后 set({...})。

两者可以共存，按模块逐个迁移，不需要一次性重构。

总结

选型看约束需求：需要强约定、时间旅行、RTK Query 和团队规范，用 Redux Toolkit，付出约 18 kB 体积和样板代码；需要轻量、少样板、快速接入，用 Zustand 5.x，约 1.2 kB，但要在 selector 返回对象时用 useShallow 防无限循环。性能不是决策依据，两者都能做到按字段精确订阅。