⚡ 30 秒速记
- 核心判断：状态管理的核心是把状态变化约束成可追踪的数据流，中间件在派发边界扩展异步、日志和副作用
- 原理主线：围绕 「一、index.js」、「二、createStore.js」、「三、combineReducers.js」 建立输入、状态变化与输出之间的因果关系
- 文章范围：分析Redux源码，详细讲解其核心原理与实现机制，帮助读者全面理解Redux的设计思想与工作流程。
- 边界与代价：集中式状态不是越多越好；可变性、订阅粒度和异步取消决定性能与可维护性
- 工程落地：选型要从状态归属、更新频率、调试需求和团队约束出发，而不是只比较 API 数量
Redux 的核心是让状态只能沿着 dispatch、reducer、新状态这条可追踪链路变化，中间件则扩展派发过程。 createStore 保存状态和订阅者，创建时会派发初始化动作；后续动作进入队列，由 reducer 计算下一份状态。combineReducers 按键拆分状态，bindActionCreators 只是把动作创建函数包装成自动派发。像 thunk、日志这类能力放在中间件中，通过 next 串联，避免侵入状态计算。
这篇文章不要按 API 清单来背。先用上面的 Mind Map 建立全局结构，再通过交互 DEMO 观察正常路径和边界路径如何改变状态；阅读正文时重点核对每一步的输入、负责执行的参与者、产生的中间状态以及最终可观察结果。遇到版本敏感结论，要把“历史实现”“当前行为”和“工程兼容策略”分开说明；遇到性能或架构取舍，则用实际指标、失败现象和验证手段支撑判断。
版本校准： 本文若分析 ReactDOM.render、旧生命周期或栈调和，应把它视为理解架构演进的历史路径。React 19 已移除 ReactDOM.render，当前客户端入口使用 createRoot；并发渲染也必须区分可中断的渲染阶段与同步提交阶段。迁移前对照 React 19 官方升级指南。
# 一、index.js
- 暴露了几个核心
API
import createStore from './createStore';
import combineReducers from './utils/combineReducers';
import bindActionCreators from './utils/bindActionCreators';
import applyMiddleware from './utils/applyMiddleware';
import compose from './utils/compose';
export {
createStore,
combineReducers,
bindActionCreators,
applyMiddleware,
compose
};
