⚡ 30 秒速记

• 核心判断：状态管理的核心是把状态变化约束成可追踪的数据流，中间件在派发边界扩展异步、日志和副作用
• 原理主线：围绕 「一、前言」、「二、为什么要引入middleware」、「三、中间件是如何工作的」 建立输入、状态变化与输出之间的因果关系
• 文章范围：解析Redux中间件的原理、作用及其在Redux数据流中的应用，帮助开发者理解如何通过中间件扩展Redux功能，实现异步操作、日志记录等高级用法。
• 边界与代价：集中式状态不是越多越好；可变性、订阅粒度和异步取消决定性能与可维护性
• 工程落地：选型要从状态归属、更新频率、调试需求和团队约束出发，而不是只比较 API 数量

Redux 中间件位于 dispatch 与 reducer 之间，本质上是对派发能力的扩展。 applyMiddleware 会把多个中间件组合成调用链，每个中间件通过 next(action) 把控制权交给下一环。以 redux-thunk 为例，遇到函数就执行并注入 dispatch、getState，遇到普通对象则继续传递。自定义中间件如果漏掉 next(action)，后续中间件和 reducer 都收不到这个 action。

这篇文章不要按 API 清单来背。先用上面的 Mind Map 建立全局结构，再通过交互 DEMO 观察正常路径和边界路径如何改变状态；阅读正文时重点核对每一步的输入、负责执行的参与者、产生的中间状态以及最终可观察结果。遇到版本敏感结论，要把“历史实现”“当前行为”和“工程兼容策略”分开说明；遇到性能或架构取舍，则用实际指标、失败现象和验证手段支撑判断。

版本校准： 本文若分析 ReactDOM.render、旧生命周期或栈调和，应把它视为理解架构演进的历史路径。React 19 已移除 ReactDOM.render，当前客户端入口使用 createRoot；并发渲染也必须区分可中断的渲染阶段与同步提交阶段。迁移前对照 React 19 官方升级指南。

一、前言

• 在redux里，middleware是发送action和action到达reducer之间的第三方扩展，也就是中间层。也可以这样说，middleware是架在action和store之间的一座桥梁
• 在redux里，action仅仅是携带了数据的普通js对象

Reducer 拆分可以使组件获取其最小属性(state)，而不需要整个Store。中间件则可以在Action Creator 返回最终可供 dispatch 调用的 action 之前处理各种事情，如异步API调用、日志记录等，是扩展 Redux 功能的一种推荐方式

• Redux 提供了 applyMiddleware(...middlewares) 来将中间件应用到 createStore。applyMiddleware 会返回一个函数，该函数接收原来的 creatStore 作为参数，返回一个应用了 middlewares 的增强后的 creatStore