⚡ 30 秒速记

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

Redux 中间件是在 dispatch 与 reducer 之间扩展动作处理能力的一层机制。 applyMiddleware 会增强原来的 dispatch，再用 compose 把多个中间件串成调用链，因此日志、异步任务等逻辑不必塞进 reducer。以 redux-thunk 为例，遇到函数动作就执行它并传入 dispatch、getState，普通对象则交给 next。自定义中间件如果漏掉 next(action)，后续中间件和 reducer 都收不到该动作。

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

版本校准： 原理文章中的代码代表特定实现与写作时间。应用到当前项目时，应先确认浏览器、框架或工具的主版本，再区分稳定的规范语义、可变化的内部实现和项目自身约束。

一、前言

• 在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