Electrolux_blog关键设计决策和原因
Redux 的约束（纯函数、单 store、plain action）都是可预测性与 DevTools 时间旅行 的代价。下表为速查；细节见各专题章。
1. 单一 Store
| 收益 | 代价 |
|---|---|
| 一处 getState、调试简单 | 大应用需 combineReducers 分 slice |
| 时间旅行一致 | 模块化靠命名空间而非多 store |
2. subscribe 不传 state
| 收益 | 代价 |
|---|---|
| API 稳定、避免「快照时点」争论 | listener 需自调 getState() |
react-redux 在之上做 selector 快照。
3. Middleware 柯里化三层
| 收益 | 代价 |
|---|---|
| 创建期绑定 store/next，性能好 | 学习曲线 |
见 04。
4. combineReducers 不传全局 state
| 收益 | 代价 |
|---|---|
| slice 独立、易测、易组合 | 跨 slice 逻辑用 selector 或 middleware |
5. Action 必须 plain object
| 收益 | 代价 |
|---|---|
| 可序列化、DevTools、可预测 | 异步靠 middleware |
6. Reducer 必须纯函数
| 收益 | 代价 |
|---|---|
| 可重放、可测 | 副作用外置 |
7. 引用相等性
| 收益 | 代价 |
|---|---|
| 未变 slice 可跳过渲染（配合 react-redux） | reducer 需返回原引用当无变化 |
8. type 用字符串
| 收益 | 代价 |
|---|---|
| 可序列化、跨端 | 需命名规范防冲突 |
Symbol action 不支持。
与 Zustand 选型
| 选 Redux | 选 Zustand |
|---|---|
| 强约束团队、DevTools、中间件生态 | 小团队、要极简、Hooks 优先 |
| RTK Query 数据层 | 本地 UI + 中等全局态 |
总结
Redux 用严格边界换可推理；若不需要时间旅行与统一 action 日志，可考虑更轻的 Zustand。