Redux没错，但开发者已经投票用脚了

Redux曾经是React生态的"国王"，但最近的技术社区里，你会频繁看到这样的声音：

"我们用Zustand替代了Redux，删除了好几百行代码" "Redux就像企业级的仪式感，而Zustand让我专注于真正的产品逻辑"

这不是简单的工具更新，而是一场关于工程体验和开发效率的代际差异。本文将从原理层面剖析这个变化背后的深层原因。

第一部分：Redux为什么开始"掉队"

Redux的设计初心

Redux本身的设计理念是完美的：单一数据源、可预测的状态流、时间旅行调试。这些特性在当年大型团队的复杂项目中确实发挥了巨大作用。

但是——

问题的根源：仪式感陷阱

Redux要求你遵循一套完整的工作流程：

开发需求
  ↓
定义 Action Type（常量）
  ↓
编写 Action Creator（函数）
  ↓
编写 Reducer（纯函数）
  ↓
用 combineReducers 整合
  ↓
用 Provider、useSelector、useDispatch 连接组件
  ↓
考虑是否需要中间件（middleware）

让我们用一个最简单的例子看看：一个计数器加1。

Redux的做法（典型的redux+reducer模式）

// 1️⃣ 定义 action type
const INCREMENT = 'INCREMENT';
const DECREMENT = 'DECREMENT';

// 2️⃣ 编写 action creator
function increment() {
return { type: INCREMENT };
}

function decrement() {
return { type: DECREMENT };
}

// 3️⃣ 编写 reducer（必须是纯函数）
function counterReducer(state = 0, action) {
switch(action.type) {
    case INCREMENT:
      return state + 1;
    case DECREMENT:
      return state - 1;
    default:
      return state;
  }
}

// 4️⃣ store 配置
import { createStore } from'redux';
const store = createStore(counterReducer);

// 5️⃣ 在组件中使用
import { useSelector, useDispatch } from'react-redux';

function Counter() {
const count = useSelector(state => state);
const dispatch = useDispatch();

return (
    <div>
      <p>{count}</p>
      <button onClick={() => dispatch(increment())}>+1</button>
      <button onClick={() => dispatch(decrement())}>-1</button>
    </div>
  );
}

这是5个文件/5个步骤，只为了实现一个简单的计数器。

而且这还不是最复杂的场景。当你需要：

• 处理异步操作？需要 redux-thunk 或 redux-saga
• 调试？需要 redux-devtools
• 规范化数据？需要考虑 selector 的性能优化
• 处理大型 action payload？需要处理 immer 或 immutability 的问题

你会发现自己在写框架代码而不是业务代码。

数据说话：Redux的成本

根据社区的实测反馈，一个中等规模的Redux项目迁移到Zustand：

第二部分：Zustand的极简哲学

什么是Zustand？

Zustand是由React Spring和Jotai的作者设计的极简状态管理库。它抛弃了Redux的"仪式感"，回归到最本质的状态管理——一个简单的JS对象 + 订阅系统。

同样的计数器，Zustand怎么做

import { create } from'zustand';

// 就这么简单
const useCounterStore = create((set) => ({
count: 0,

increment: () =>set((state) => ({ count: state.count + 1 })),
decrement: () =>set((state) => ({ count: state.count - 1 }))
}));

// 在组件中直接用
function Counter() {
const { count, increment, decrement } = useCounterStore();

return (
    <div>
      <p>{count}</p>
      <button onClick={increment}>+1</button>
      <button onClick={decrement}>-1</button>
    </div>
  );
}

就这样。一个文件。核心逻辑3行。

为什么Zustand能这样简洁？

深层的原因在于API设计哲学的差异：

Redux的假设：

• 状态必须通过 reducer 这个"中介" 修改
• 必须有 action creator 作为"合同"
• 必须通过 dispatch 这个"邮差"传递
• 目的是确保绝对的可追溯性

Zustand的假设：

• 状态就是状态，函数就是函数
• 信任开发者不会乱来
• 通过闭包直接暴露更新方法
• 目的是最小化认知负担

这不是技术问题，而是哲学问题。

第三部分：硬核对比——底层实现的差异

体积对比

Redux (redux):        12.3 KB (min+gzip)
Zustand:              1.2 KB (min+gzip)

为什么差10倍？因为Redux需要：

• Action dispatch 系统
• Reducer 组合系统
• 中间件系统
• DevTools 集成基础设施

而Zustand只需要：

• 闭包管理状态
• WeakMap 管理订阅
• 简单的更新触发

渲染性能的真相

这是很多人关心的问题。我们来看实际情况：

Redux 的渲染流程：

dispatch(action)
  ↓
reducer 运算
  ↓
createSelector 计算新状态
  ↓
React.memo 判断是否重新渲染
  ↓
组件重新渲染

中间有多个"关卡"，每个关卡都需要开发者手动优化。

Zustand 的渲染流程：

set((state) => ({ ... }))
  ↓
WeakMap 查询订阅者
  ↓
订阅该状态的组件 hook 触发更新
  ↓
组件重新渲染

更直接，更细粒度。Zustand 在 hook 层面就知道谁依赖了什么数据，所以不会有"我改了全局状态，半个应用都重新渲染"的情况。

实战测试（中等规模项目）：

第四部分：实战场景剖析

场景1：中小型项目（初创/小团队）

用Redux的成本：

• 项目本身代码 500行
• Redux 配置和 boilerplate 代码 300-400行
• 新成员学习周期 2-3周

用Zustand的成本：

• 项目本身代码 500行
• Zustand store 代码 50-100行
• 新成员学习周期 2-3天

结论：Zustand 节省 70% 的配置成本

场景2：大型复杂项目（大厂/长期维护）

这里Redux可能还有优势吗？让我们看一个真实案例：

产品管理系统（用户、权限、表单状态等复杂交互）

Redux 的优点：

• 严格的架构约束帮助新人快速适应
• Redux DevTools 的时间旅行调试在复杂bug排查时很有用
• 强制的 pure reducer 防止隐藏的副作用

但是，Zustand 也能做到这些，只是：

• 架构约束需要团队自律（而不是工具强制）
• Zustand 可以配合 immer 中间件实现不可变更新
• 搭配浏览器 DevTools 扩展也能调试

关键问题：是否值得为了这些优点付出 60% 的代码复杂度代价？

大多数团队的答案是：不值得。

场景3：超大规模应用（类似Facebook/Airbnb规模）

只有在这个级别，Redux 的优势才真正体现：

• 500+ 开发者，需要强制的规范
• 多个业务线，需要完全的可追溯性
• 性能关键路径需要每一ms的优化

但即使在Meta，也有团队使用 Recoil（Facebook自家的替代品）而不是 Redux。

第五部分：迁移决策树

你正在选择状态管理工具

├─ 项目是否已经用了Redux？
│  ├─ 否 → 优先选择 Zustand
│  │
│  └─ 是 → 继续下一个问题
│
├─ Redux 中是否用到了以下功能？
│  ├─ redux-middleware（thunk/saga）
│  ├─ redux-devtools 的时间旅行功能
│  ├─ 复杂的规范化数据结构（normalizr）
│  │
│  ├─ 以上都有 → 继续用Redux（或升级到 Redux Toolkit）
│  └─ 都没有 → 可以考虑迁移到Zustand
│
└─ 新功能/模块开发
   └─ 用Zustand 开发新模块（增量迁移）

第六部分：深度思考——为什么会发生这个转变

原因1：React 本身的进化

• Redux 设计于 Class Component 时代
• 那时候状态提升是个大问题，需要集中管理
• 但 Hooks 的出现改变了游戏规则

Hooks 让状态管理变得更加本地化和组合化。Redux 那一套集中式管理的必要性大大降低了。

原因2：开发者心态的变化

从 2015 年到现在，前端工程师对代码清晰度的追求超过了对架构宏大性的追求。

• Redux 强调"一切尽在掌控"
• Zustand 强调"代码即它本身"

现代开发者倾向于后者。

原因3：工具链的成熟

Redux 当年的一大卖点是 DevTools 调试能力。但现在：

• Chrome DevTools 已经非常强大
• React DevTools 可以展示所有 hook 状态
• 浏览器原生支持很多 Redux 需要插件才能做的事

Redux 的垄断优势消失了。

最后的思考

Redux 会死吗？

不会。Redux Toolkit 已经让 Redux 的使用体验提升了一个数量级。很多大型项目依然在用，而且运行得很好。

那为什么开发者还在逃离？

因为选择自由。当一个更轻量、更贴近 React 哲学的工具出现时，很少有理由继续忍受 Redux 的"仪式感"。

终极建议

真正的智慧不是选择最强大的工具，而是选择最适合当前阶段的工具。

2025年的 React 社区已经做出了选择。下一个问题是：你的团队什么时候开始迁移？

相关资源

• Zustand 官方文档
• Redux vs 现代替代品对比
• React Hooks 与状态管理