为什么 Redux 值得你认真对待（哪怕你只用 React）

很多人在学习 Redux 时，第一反应是：“我为什么要多写这么多代码？” 这种困惑很正常。但 Redux 真正解决的，从来不是“少写代码”，而是让状态变化变得可预测、可追溯、可测试。

核心只有三个词：Store、Action、Reducer

如果用一句话描述 Redux 的工作方式：

事件（Action）描述“发生了什么”，纯函数（Reducer）决定“如何更新”，仓库（Store）持有“当前状态”。

这段代码几乎概括了全部骨架：

import { createStore } from 'redux'

// 1. Reducer：纯函数，接收旧状态和 action，返回新状态
function counter(state = 0, action) {
  switch (action.type) {
    case 'INCREMENT': return state + 1
    case 'DECREMENT': return state - 1
    default: return state
  }
}

// 2. Store：持有状态，提供 dispatch 和 getState
const store = createStore(counter)

// 3. Action：描述意图
store.dispatch({ type: 'INCREMENT' })
console.log(store.getState()) // 1

你看，数据是单向流动的： View → dispatch(action) → Reducer → new State → View 更新

为什么这很重要？

因为当应用变大，状态散落在各个组件中时，任何两个组件共享的数据都可能成为隐患。Redux 强制你把所有“可变操作”集中到 reducer 里，并且每次更新都生成新对象（不可变）。

这就带来了几个实际好处：

• 时间旅行调试：每一步 action 都能回放
• 错误更容易定位：你清楚哪个 action 引发了异常
• 服务端渲染、状态持久化变得很自然

你不需要把所有状态都放进 Redux

这是新手最容易踩的坑。 正确做法是：局部 UI 状态用 useState/useReducer，跨组件、全局或缓存数据用 Redux。

比如表单输入、开关状态，完全可以留在组件内；而用户信息、主题设置、列表数据，才是 Redux 的合适场景。

现代 Redux 已经简洁很多

早期 Redux 被诟病“模板代码太多”，但官方 Toolkit（Redux Toolkit）大幅简化了写法：

import { createSlice, configureStore } from '@reduxjs/toolkit'

const counterSlice = createSlice({
  name: 'counter',
  initialState: 0,
  reducers: {
    increment: state => state + 1,   // 允许“写”语法，底层用 Immer
    decrement: state => state - 1,
  }
})

const store = configureStore({ reducer: counterSlice.reducer })
store.dispatch(counterSlice.actions.increment())

你甚至不需要手动写 action types 和 action creators。

一句话总结

Redux 不是用来“节省代码量”的，它是用来管理复杂度的。 如果你的应用状态足够简单，不必用它；但如果状态开始“牵一发动全身”，Redux 的约束会成为你最可靠的伙伴。

状态管理工具很多，但 Redux 的设计哲学——单一数据源、状态只读、纯函数更新——至今仍是理解前端数据流的最佳入门范式。

如果你想继续深入，下一步可以看 中间件（Middleware） 如何处理异步（比如 thunk），以及 Selector 如何做派生状态。那才是 Redux 真正发挥威力的地方。