redux 本身有什么不足？

Redux 是 React 生态中最经典的状态管理方案之一，但它确实有不少天然不足和使用痛点。

一、Redux 本身的不足

样板代码太多（Boilerplate Code）

Redux 的核心理念是「可预测状态变化」，这导致：

• 你必须写大量的样板代码（actions、action types、reducers）。

• 就算只是改一个简单的值，也要：

定义 action type

写 action creator

在 reducer 里 switch case

在组件里 dispatch。

例如：

// actions.js
export const INCREMENT = 'INCREMENT';
export const increment = () => ({ type: INCREMENT });

// reducer.js
export default function counter(state = 0, action) {
  switch (action.type) {
    case INCREMENT:
      return state + 1;
    default:
      return state;
  }
}

// 组件中
dispatch(increment());

一个小功能就要三四个文件，维护成本高。

心智负担高

Redux 有很多抽象概念：

• Store、Reducer、Action、Middleware、Dispatch、Selector...

• 初学者需要理解数据流：单向流动、不可变更新、纯函数 reducer。这对新手不太友好，学习曲线陡峭。

异步逻辑复杂

Redux 最初只支持同步更新，异步操作要靠中间件，比如：

• redux-thunk

• redux-saga

• redux-observable

每个中间件都有不同的写法和理念，选择和维护都复杂。

在异步场景下，Redux 代码常常膨胀得非常快。

性能问题

Redux 的状态是全局的，任何状态更新都会触发订阅组件的重新渲染。
虽然可以通过 connect + mapStateToProps 优化，但：

• 容易因为引用不变性导致重复渲染；

• 对性能优化的要求高；

• React 18 出现后，Redux 老式写法不完全匹配新架构（如 concurrent rendering）。

数据流更新不直观

Redux 的更新过程太“间接”：

组件 → dispatch(action) → reducer → store → provider → 组件更新

这对简单的局部状态（比如表单输入、UI 控制）来说太笨重了。
在很多场景，React 自带的 useState / useReducer 足够。

调试虽强但依赖重

虽然 Redux DevTools 很强大，但：

• 依赖 Chrome 插件；

• 对于大项目中复杂异步流，trace 仍然困难；

• 开发环境与生产环境差异大（例如 middleware 配置）。

二、社区为了解决这些问题的改进

问题	改进方案
样板代码太多	Redux Toolkit (RTK) 自动封装 reducer、action、immer
异步复杂	RTK Query / createAsyncThunk 简化异步逻辑
性能问题	useSelector + memo + RTK 内部优化
学习曲线高	RTK 文档强调“少写样板，多用工具”
代码冗长	RTK 的 createSlice 让一个文件内定义所有逻辑

使用 Redux Toolkit 的写法更现代

import { createSlice } from '@reduxjs/toolkit'

const counterSlice = createSlice({
  name: 'counter',
  initialState: 0,
  reducers: {
    increment: state => state + 1,
  },
});

export const { increment } = counterSlice.actions;
export default counterSlice.reducer;

现在只需要一个文件、几行代码就能完成以前的三倍工作量。

三、Redux 的本质地位

Redux 并没有“过时”，它在大型应用中仍然强大，但：

• 对于中小项目，React 自带的 Context + useReducer 已经够用。

• 对于数据请求类项目，可以直接用 RTK Query、React Query、Recoil、Zustand 等替代。

总结

缺点	说明	对应解决方案
样板代码多	写太多重复逻辑	Redux Toolkit
学习曲线陡	概念多、流程复杂	官方文档 + Toolkit
异步复杂	依赖中间件	createAsyncThunk、RTK Query
性能优化难	全局状态引起重渲染	useSelector + memo
小项目臃肿	管理成本高	直接用 useState / Recoil / Zustand