Redux：状态管理的"单一真相"

原创

资源shanxueit.com

修改于 2026-08-17 17:25:45

120

一个前端开发的真实困境

假设你正在开发一个电商应用。用户把商品加入购物车，购物车角标要更新，商品详情页的"加入购物车"按钮要变成"已加入"，购物车列表要同步变化，结算页面要显示新的总价。

如果每个组件都维护自己的"购物车状态"，你会发现：同样一个"加入购物车"操作，需要手动更新5个不同的地方。更可怕的是，某次操作后角标变了但列表没变，总价算错了但商品数量对了——UI出现各种不一致。

这不是代码写得不好，而是状态管理方式出了问题。当多个组件需要共享同一份数据时，传统"自下而上"的状态管理就会变得混乱不堪。

Redux的核心思想正是为了解决这个问题：把共享状态集中管理，让所有组件都从同一个地方读取数据。

Redux的三大原则

理解Redux，首先理解它的三大设计原则。这三条原则看似简单，但深刻影响了整个前端状态管理的走向。

原则一：单一数据源

整个应用的状态存储在一个JavaScript对象树中，存储在一个Store里。

// 整个应用的状态树
{
  cart: {
    items: [{id: 1, name: '手机', quantity: 2}],
    totalPrice: 5998
  },
  user: {
    id: '001',
    name: '张三',
    isLoggedIn: true
  },
  product: {
    currentProduct: {id: 1, name: '手机', price: 2999},
    productList: [...]
  }
}

为什么重要？ 当所有状态集中在一起时，调试变得极其简单。你只需要检查这一个对象，就知道整个应用的状态。没有"这个数据在哪个组件里"的困惑。

原则二：状态是只读的

不能直接修改状态。唯一改变状态的方式是触发一个Action，描述"发生了什么"。

// ❌ 错误：直接修改状态
store.state.cart.items.push(newItem);

// ✅ 正确：触发Action
store.dispatch({
  type: 'ADD_TO_CART',
  payload: { productId: 1, quantity: 1 }
});

为什么重要？ 当所有状态变更都通过Action发生时，每一个变更都有迹可循。你可以追踪每一个Action，理解"这个状态是怎么变成这样的"。这就是Redux DevTools能实现"时间旅行调试"的基础。

原则三：用纯函数执行修改

Reducer必须是一个纯函数：给定相同的输入（旧状态和Action），永远返回相同的输出（新状态）。没有副作用，不修改传入的状态，不调用API。

// 纯函数的Reducer
function cartReducer(state = { items: [], total: 0 }, action) {
  switch (action.type) {
    case 'ADD_TO_CART':
      // 返回新对象，不修改原状态
      return {
        ...state,
        items: [...state.items, action.payload]
      };
    default:
      return state;
  }
}

为什么重要？ 纯函数让Reducer易于测试、易于预测。你只需要测试"给定这个State和这个Action，会返回什么新State"，不需要模拟任何外部环境。

Redux的核心概念

Store：状态的大本营

Store是Redux的核心，它持有整个应用的状态树。Store的作用是：

存储状态：整个应用的状态都存在这里
提供getState()：让组件获取状态
提供dispatch()：让组件触发状态变更
提供subscribe()：让组件订阅状态变化

Action：状态变更的"命令"

Action是一个普通的JavaScript对象，必须包含type字段。它描述"发生了什么事"，但不关心"如何改变状态"：

下载

// Action的格式
{
  type: 'ADD_TO_CART',
  payload: {
    productId: 123,
    quantity: 2
  }
}

Action是信息的载体，它承载着从UI到Store的消息。任何状态变更，都必须通过发送Action来实现。

Reducer：状态变更的"执行者"

Reducer接收当前状态和Action，返回新状态。它是真正"执行"状态变更的地方：

function cartReducer(state = [], action) {
  switch (action.type) {
    case 'ADD_TO_CART':
      // 如果已存在，增加数量；否则新增
      const existing = state.find(item => item.id === action.payload.id);
      if (existing) {
        return state.map(item => 
          item.id === action.payload.id 
            ? {...item, quantity: item.quantity + 1}
            : item
        );
      }
      return [...state, {...action.payload, quantity: 1}];
      
    case 'REMOVE_FROM_CART':
      return state.filter(item => item.id !== action.payload.id);
      
    default:
      return state;
  }
}

Reducer是纯函数，每次返回的都是全新的状态对象，从不修改原状态。

Redux的工作流

一个完整的Redux数据流是这样的：

下载

用户操作（点击按钮）
    ↓
dispatch(Action)   ← 组件发送Action
    ↓
Store调用Reducer  ← Store把当前State和Action传给Reducer
    ↓
Reducer返回新State ← Reducer根据Action计算新状态
    ↓
Store更新State
    ↓
组件重新渲染   ← UI自动更新

这就是单向数据流：View → Action → Reducer → State → View。数据永远沿着一个方向流动，状态变更可追溯、可预测。

Redux的经典使用场景

场景一：跨组件共享状态

登录状态、用户信息、全局配置，这些被多个组件共享的数据，适合放在Redux中。

场景二：复杂的状态逻辑

购物车、表单状态、多步流程，这些状态逻辑复杂、涉及多个操作的地方，Redux能清晰管理。

场景三：状态持久化和恢复

从LocalStorage恢复状态、服务端渲染时注入初始状态，Redux的集中管理让这些变得容易。

场景四：需要时间旅行调试

当应用状态逻辑复杂，需要回溯"状态是怎么变成这样的"，Redux DevTools能提供强大支持。

Redux的"过度工程"陷阱

Redux很强大，但不是所有场景都需要Redux。

什么时候不需要Redux？

简单的UI状态（弹窗开关、Tab切换）→ 用组件自身的state即可
只在父子组件间传递的数据 → 用props传递
应用规模小、团队人数少 → useState + useContext就够了

什么时候该用Redux？

多个组件共享同一份数据
状态变更逻辑复杂，涉及多个步骤
应用规模大，团队协作需要统一的状态管理规范
需要强大的调试能力

// 简单场景：用useState就足够了
function ToggleButton() {
  const [isOpen, setIsOpen] = useState(false);
  return <button onClick={() => setIsOpen(!isOpen)}>
    {isOpen ? '关闭' : '打开'}
  </button>;
}

// 复杂场景：用Redux管理全局状态
// 用户信息被Header、Profile、Settings等多个组件使用
// 登录、登出、更新资料等操作涉及多个步骤

Redux的"三大痛点"与现代替代方案

传统Redux有3个被开发者吐槽最多的地方：

痛点一：样板代码太多

定义一个Action要写Action Type常量、Action Creator、Reducer case。一个简单的操作要写三份代码。

痛点二：异步处理复杂

原生Redux不支持异步Action，需要引入Redux Thunk或Redux Saga。新手常常被异步流程搞晕。

痛点三：修改状态的"不可变"要求

每次都要手动创建新对象（...state），不小心就直接修改了原状态，导致Bug难找。

// 传统Redux的样板代码
// 1. 定义Action Type
const ADD_TODO = 'ADD_TODO';

// 2. 定义Action Creator
function addTodo(text) {
  return { type: ADD_TODO, payload: { text } };
}

// 3. 在Reducer中处理
case ADD_TODO:
  return {
    ...state,
    todos: [...state.todos, { text: action.payload.text, completed: false }]
  };

新时代的状态管理

React 16.8引入了Hooks，极大改变了状态管理生态：

useReducer + useContext：对于中小型应用，用React自带的Hooks就能实现Redux式的状态管理，无需引入外部库。

Redux Toolkit：Redux官方推出的"现代化Redux"，内置了Immer（让不可变更新变得简单）、Redux Thunk（处理异步）、自动组合Reducer等能力。将样板代码减少了70%以上。

// Redux Toolkit：10行代码完成之前30行的功能
import { createSlice } from '@reduxjs/toolkit';

const cartSlice = createSlice({
  name: 'cart',
  initialState: { items: [], total: 0 },
  reducers: {
    addItem: (state, action) => {
      // 注意：这里可以直接"修改"state！
      // Immer在底层自动处理了不可变更新
      state.items.push(action.payload);
      state.total += action.payload.price;
    },
    removeItem: (state, action) => {
      const index = state.items.findIndex(item => item.id === action.payload);
      if (index !== -1) {
        state.total -= state.items[index].price;
        state.items.splice(index, 1);
      }
    }
  }
});

export const { addItem, removeItem } = cartSlice.actions;
export default cartSlice.reducer;

Zustand、Jotai、Recoil：新一代轻量级状态管理库，API更简洁、学习曲线更平缓，正在成为Redux之外的热门选择。

写在最后

Redux诞生于2015年，至今仍是React生态中最具影响力的状态管理方案。它的价值不仅在于技术本身，更在于它推广的"单向数据流、单一数据源、状态只读"的设计思想。

理解了这些思想，你就能理解Redux、也能理解为什么Zustand简化了API但保留了核心思想、也能理解为什么useReducer + useContext能解决很多问题。

Redux给你的不是代码模板，而是一种思考状态的方式。 当你学会"把状态集中管理、用Action描述变更、用纯函数执行变更"这套方法论后，你就能在任何技术栈中写出更清晰、更可维护的代码。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

redux