按照指南，我找到了各种用于redux应用程序的中间件。
Redux Thunk，Redux Promise，Redux Promise Middleware，Redux Observable，Redux Saga，Redux Pack
我们选择哪种中间件只是一个偏好问题。但我并不是要求选择一个会议。
我想知道它们之间是否有任何差异，如性能，浏览器支持，用例等。或者我缺少的任何其他内容。我对这些进行了艰苦的研究，但却找不到任何文章。
这样我就可以考虑为我的应用程序选择一个中间件。如果我知道具有不同中间件的特定用例，那么选择中间件也是很好的。
或者，所有中间件都只是约定，我可以为任何类型的redux应用程序（小型或大型）选择其中任何一种？
答案 0 :(得分：4)
To be able to choose one of these libraries我们必须考虑我们是在构建一个小型还是大型应用程序。还可以考虑可用性，代码标准和JavaScript知识。所有这些都是相似的。
<强>终极版-形实转换
Redux Thunk中间件允许您编写返回函数而不是动作的动作创建者。 thunk可用于延迟动作的发送，或仅在满足某个条件时发送。它将方法dispatch和getState作为参数合并。
<强>终极版-佐贺
redux-saga是一个旨在以可管理和有效的方式执行应用程序副作用（即异步，如数据获取和不纯的过程，如访问浏览器缓存）的库。它的测试很简单，因为它使用称为生成器的ES6特性，使得流程易于作为同步代码读取。
<强>终极版可观察
redux-observable是redux的中间件，受到redux-thunk的启发。它允许开发人员调度返回Observable，Promise或可迭代操作的函数。当observable发出一个动作，或者promise解决一个动作，或者iterable给出一个动作时，那个动作就像往常一样被派遣。
其他人直接来自他们的github来源：
redux-promise
中间件向调用者返回一个promise，以便它可以在继续之前等待操作完成。这对于服务器端呈现特别有用。
<强>终极版-承诺中间件
Redux promise中间件可以在Redux中实现对异步操作创建者的可靠处理：它接受一个promise并发送待处理，已完成和被拒绝的操作。 中间件也可以与Redux Thunk结合使用，以连锁动作创建者。
<强>终极版包装
redux-pack是一个引入基于承诺的中间件的库，它允许基于promise的生命周期的异步操作是声明性的。
redux中的异步操作通常使用redux-thunk或其他中间件来完成。这种方法的问题在于它使得顺序使用调度变得太容易，并且调度多个＆＃34;动作＆＃34;作为相同的交互/事件的结果，他们可能应该只是一个单一的行动调度。
这可能会有问题，因为我们将多个调度视为单个事务的所有部分，但实际上，每个调度都会导致对整个组件树进行单独的重新呈现，我们不仅要付出巨大的性能损失，还要承担风险redux存储处于不一致状态。
redux-pack有助于防止我们犯这些错误，因为它没有赋予我们调度功能的强大功能，但允许我们完成以前所做的所有事情。
答案 1 :(得分：2)
根据我的个人经验（我已经使用了你列出的大部分中间件）。
Redux Saga是要走的路。它具有更高的学习曲线，但是一旦你绕过它，它就会变得非常强大
Redux Saga
一旦了解了redux saga，扩展应用程序就变得容易多了。
https://engineering.universe.com/what-is-redux-saga-c1252fc2f4d1