• 如果您需要将中间件用于各种目的。例如，记录操作，错误报告，根据服务器的响应调度其他请求等。
• 当来自多个端点的数据影响单个组件/视图时。
• 当您想更好地控制应用程序中的操作时。Redux可以跟踪动作和数据更改，从而极大地简化了调试。
• 如果您不希望服务器响应直接更改应用程序的状态。Redux添加了一层，您可以在其中决定如何，何时以及是否应应用此数据。观察者模式。您只需将组件连接到Redux商店，而不是在整个应用程序中创建多个发布者和订阅者。

来自：何时使用Redux？

如果仅在使用Redux以避免将props传递到深度嵌套的组件中，则可以使用ContextAPI 替换Redux 。正是针对此用例。

另一方面，如果您将Redux用于其他所有功能（具有可预测的状态容器，在组件外部处理应用程序的逻辑，集中应用程序的状态，使用Redux DevTools来跟踪何时，何地，原因以及应用程序的状态更改，或使用诸如Redux Form，Redux Saga，Redux Undo，Redux Persist，Redux Logger等之类的插件），那么您绝对没有理由放弃Redux。该ContextAPI不提供任何这一点。

我个人认为Redux DevTools扩展是一个了不起的，被低估的调试工具，它本身证明继续使用Redux是合理的。

一些参考：

• Redux还没有死！
• 您可能不需要Redux
• React Hook可以代替Redux吗？

我更喜欢将redux与redux-thunk一起使用来进行API调用（也使用Axios）并将响应分配给reducer。它很干净而且易于理解。

上下文API专门针对react-redux部分，介绍如何将React组件连接到商店。为此，react-redux很好。但是，如果您愿意，由于正式支持Context，则可以使用Context API代替r​​eact-redux。

因此，问题应该是Context API vs react-redux，而不是Context API vs redux。另外，这个问题有些人自以为是。由于我熟悉react-redux并将其在所有项目中使用，因此我将继续使用它。（我没有动力去改变）。

但是，如果您只是在今天学习redux，并且没有在任何地方使用过，那么值得一试Context API，并用您的自定义Context API代码替换react-redux。也许，这样更清洁。

就个人而言，这是一个熟悉的问题。没有明显的理由选择一个，因为它们是等效的。而且在内部，react-redux仍然使用Context。

对我使用Redux的唯一原因是：

• 您需要一个全局状态对象（出于各种原因，例如可调试性，持久性...）
• 您的应用规模很大或将会很大，并且应该可以扩展到许多开发人员：在这种情况下，您可能需要一定程度的间接（即事件系统）：您触发事件（过去），然后在您不认识的人中组织实际上可以听他们的

您可能不需要整个应用程序的间接级别，因此可以混合使用样式，并同时使用本地状态/上下文和Redux。