前言
在 React 生态中，状态管理一直是开发者绕不开的话题。Redux 以其严谨的"单向数据流"闻名，虽然有一定的学习成本，但它为大型项目带来的可预测性和可调试性是无可替代的。本文将带你深度复盘 Redux 的核心逻辑。
一、 Redux 的核心
Redux 的核心思想是将应用的所有状态（State）集中存储在一个唯一的 Store 中，并遵循严格的规则进行更新，让状态变化可追踪、可调试，大幅降低复杂应用的状态维护成本。
1. 三大核心概念
Redux 的运行逻辑完全围绕三大核心模块展开，各司其职、互不干扰，构建了清晰的单向数据流：
1. Store（数据仓库）
- 定位 ：应用状态的唯一存储容器，整个应用有且仅有一个 Store
- 作用：承载全局状态、派发 Action、监听状态变化、整合 Reducer，是连接视图和数据的核心枢纽
- 特性：独立于组件生命周期，不会随组件销毁而消失，状态持久稳定
2. Action（动作描述）
- 定位 ：改变 State 的唯一途径，是一个普通的 JavaScript 对象
- 结构 ：必须包含
type属性（字符串类型，描述动作类型），可选携带payload属性（传递更新状态所需的数据） - 示例 ：
{ type: 'UPDATE_USER_NAME', payload: '李四' } - 本质：只描述"要做什么"，不负责"怎么做"，属于指令载体
3. Reducer（状态处理器）
- 定位 ：纯函数（固定输入必然得到固定输出，无副作用、不修改入参）
- 参数：接收两个参数------当前旧 State（prevState）、派发的 Action 对象
- 逻辑 ：根据 Action 的 type 类型，匹配对应的更新逻辑，绝不直接修改旧 State
- 规则 ：Redux 强制要求 State 不可变（Immutable），必须返回全新的 State 对象，保证状态变化可回溯、可调试
二、 Redux 的工作流程：闭环的单向流
Redux 的数据流转遵循严格的循环路径，确保了状态变化的可追踪性：
-
用户触发操作：用户在页面执行交互行为（点击按钮、输入内容、路由跳转等），组件内触发状态更新需求
-
派发 Action ：通过 Redux 提供的
dispatch方法，将封装好的 Action 对象派发出去 -
Reducer 处理：Store 自动将当前旧 State 和派发的 Action 传递给 Reducer，Reducer 根据 type 执行对应逻辑，返回新 State
-
Store 更新状态：Store 接收 Reducer 返回的新 State，替换内部旧状态
-
组件同步数据：所有订阅了 Store 状态的组件，会自动感知状态变化，重新渲染视图，完成数据同步
注意：禁止直接修改 Store 中的 State，必须通过 dispatch 派发 Action → Reducer 生成新 State 的方式更新，这是 Redux 可预测性的核心保障。
三、 Redux vs useReducer：我该选哪个？
很多开发者会混淆这两者，虽然它们都使用了 action/reducer 模式，但在应用范围上有本质区别。
| 维度 | useReducer | Redux |
|---|---|---|
| 存储位置 | 组件内部（Local State） | 独立的全局 Store（Global State） |
| 作用域 | 仅限当前组件及其子组件 | 整个应用，任意组件均可访问 |
| 生命周期 | 随组件销毁而消失 | 独立于组件，持久存在 |
| 跨组件通信 | 需配合 useContext 并提升组件层级 |
天然支持，无需透传 Props |
场景选择：
- 使用
useReducer：逻辑复杂（有很多 if/else 或 switch），但只在单个组件或其嵌套子组件中使用。 - 使用
Redux：数据需要全局共享 。例如：用户信息需要同步更新导航栏、侧边栏和个人中心；或者需要将状态持久化到localStorage并在刷新后恢复。
四、 总结
Redux 的本质是牺牲了一定的代码简便性，换取了极致的状态可预测性。在处理跨页面同步、复杂业务逻辑以及需要状态回溯的场景下，Redux 依然是前端状态管理的王者。