我以前解释 Redux，喜欢从概念讲起：action、reducer、store、dispatch、connect。
这些名词当然重要，但如果一开始就讲名词，很多人会觉得 Redux 是 React 的必备部分。
现在我更愿意从问题出发。
Redux 不是为了让 React 更高级，而是为了解决状态变复杂之后的管理问题。
React 本身已经有状态管理
React 不是没有状态。
组件可以用
useState 管理自己的状态，也可以通过 props 把数据传给子组件。如果一个页面只有少量交互，这已经足够。
比如一个按钮计数、一个表单输入、一个弹窗开关，都不需要 Redux。
我现在判断状态管理时，会先问一个很简单的问题：这个状态是不是只属于当前组件？
如果答案是是，就让它留在组件里。
不要为了“架构完整”把简单状态搬进全局。
复杂度从组件通信开始出现
真正的问题通常从这里开始：
- 多个组件需要读同一份状态。
- 很深层的子组件要触发上层变化。
- 状态变化来源很多，难以追踪。
- 页面刷新、接口返回、用户操作会同时影响同一块数据。
- 调试时不知道状态为什么变成现在这样。
这时候只靠一层层传
props 和回调，代码会变得很绕。父组件越来越胖，子组件拿到一堆不是自己真正关心的参数，中间组件只是负责传递数据。
这就是状态需要被集中管理的信号。
Redux 的三个核心角色
我现在理解 Redux，会把它拆成三个角色。
第一，
store 是状态仓库。它让应用有一个可观察、可集中读取的状态来源。
第二，
action 是事件描述。它只说发生了什么，不直接改状态。
第三，
reducer 是状态变化规则。它接收旧状态和事件，返回新状态。
这套结构的价值，是把状态变化变得可预测：谁触发了变化，变化怎么发生，结果是什么，都可以被追踪。
Redux 不是越早用越好
我现在不会在小项目里默认引入 Redux。
原因很简单：Redux 本身也有成本。
你需要写 action、reducer、store 配置，还要约定目录结构和数据流。
如果业务还没复杂到需要这些规则，提前引入只会增加样板代码。
React 现在有
useState、useReducer、useContext，很多中小型状态都可以先用这些解决。我的判断标准是：
- 状态是否跨很多组件共享？
- 状态变化是否来自很多事件源？
- 是否需要追踪每一次变化？
- 是否需要把状态逻辑从 UI 中抽出来测试？
- 团队是否能接受 Redux 的约束？
如果这些问题大多是否，就先别用。
我会如何选择状态方案
我的路线通常是分阶段的。
第一阶段，用组件内部状态。
第二阶段，把共同状态提升到最近的公共父组件。
第三阶段，用
useReducer 管理局部复杂状态。第四阶段，用 Context 提供跨层读取。
第五阶段，当状态共享、调试、事件追踪和团队协作都变复杂后，再考虑 Redux 或类似集中状态方案。
这样做的好处是，状态管理跟着复杂度生长，而不是一开始就背上框架重量。
Redux 真正给我的启发
Redux 最重要的启发，不只是一个库。
它教我把界面状态拆成三件事：
- 当前事实是什么。
- 发生了什么事件。
- 规则如何把旧事实变成新事实。
这个思路很适合复杂前端，也适合我理解很多系统。
当一件事变复杂时，不要只看结果，要把事件、规则和状态分开。
这样系统才更容易调试，也更容易长期维护。
Loading...
