⚡ 30 秒速记
- 核心判断：状态管理的核心是把状态变化约束成可追踪的数据流，中间件在派发边界扩展异步、日志和副作用
- 原理主线：围绕 「Redux 背后的架构思想——认识 Fl」、「Flux 架构到底解决了什么问题」、「Redux 关键要素与工作流回顾」 建立输入、状态变化与输出之间的因果关系
- 文章范围：解析 Redux 的设计思想与工作原理，介绍其与 Flux 架构的关系，阐述单向数据流如何解决前端复杂应用中的数据管理难题，帮助开发者全面理解 Redux 的核心机制与实际应用场景。
- 边界与代价：集中式状态不是越多越好；可变性、订阅粒度和异步取消决定性能与可维护性
- 工程落地：选型要从状态归属、更新频率、调试需求和团队约束出发，而不是只比较 API 数量
Redux 本质上是用严格的单向数据流，让应用状态的变化变得可预测、可追踪。 组件通过 dispatch 派发 action，reducer 根据它计算新 state，store 更新后再触发订阅函数，从而把修改入口收敛到一条明确链路。执行 reducer 时，Redux 会用 isDispatching 阻止嵌套派发，避免形成递归调用。它更适合数据关系复杂的应用；状态很简单时，引入这套约束也会增加代码量和学习成本。
这篇文章不要按 API 清单来背。先用上面的 Mind Map 建立全局结构，再通过交互 DEMO 观察正常路径和边界路径如何改变状态；阅读正文时重点核对每一步的输入、负责执行的参与者、产生的中间状态以及最终可观察结果。遇到版本敏感结论，要把“历史实现”“当前行为”和“工程兼容策略”分开说明；遇到性能或架构取舍，则用实际指标、失败现象和验证手段支撑判断。
版本校准： 本文若分析 ReactDOM.render、旧生命周期或栈调和，应把它视为理解架构演进的历史路径。React 19 已移除 ReactDOM.render，当前客户端入口使用 createRoot；并发渲染也必须区分可中断的渲染阶段与同步提交阶段。迁移前对照 React 19 官方升级指南。
# Redux 背后的架构思想——认识 Flux 架构
Redux 的设计在很大程度上受益于 Flux 架构，我们可以认为 Redux 是 Flux 的一种实现形式（虽然它并不严格遵循 Flux 的设定），理解 Flux 将帮助你更好地从抽象层面把握 Redux。
Flux 并不是一个具体的框架，它是一套由 Facebook 技术团队提出的应用架构，这套架构约束的是应用处理数据的模式。在 Flux 架构中，一个应用将被拆分为以下 4 个部分。
- View（视图层）：用户界面。该用户界面可以是以任何形式实现出来的，React 组件是一种形式，Vue、Angular 也完全 OK。Flux 架构与 React 之间并不存在耦合关系。
- Action（动作）：也可以理解为视图层发出的“消息”，它会触发应用状态的改变。
- Dispatcher（派发器）：它负责对 action 进行分发。
- Store（数据层）：它是存储应用状态的“仓库”，此外还会定义修改状态的逻辑。store 的变化最终会映射到 view 层上去。
