由于Context不再是一个实验性的特性，你可以直接在你的应用程序中使用Context，它将非常适合将数据传递给深度嵌套的组件，而这正是它设计的目的。

Mark Erikson在他的博客中写道:

如果你只是使用Redux来避免传递道具，那么上下文可以 取代Redux -但你可能不需要Redux在第一 的地方。 Context也不会给你任何类似Redux DevTools的东西 能够跟踪您的状态更新，中间件添加集中 应用程序逻辑，以及其他强大的功能，Redux 使。

Redux更强大，提供了大量Context API没有提供的特性，正如@danAbramov所提到的

React Redux在内部使用上下文，但它没有将这一事实暴露在 公共API。因此，通过React使用context应该会更安全 比起直接Redux，因为如果它改变了，更新的负担就大了 代码将在React Redux上，而不是你。

它取决于Redux实际更新它的实现，以遵守最新的上下文API。

最新的上下文API可以用于在组件之间简单地使用Redux传递数据的应用程序，但是使用集中数据和处理API请求的应用程序，在动作创建者中使用Redux -thunk或Redux -saga仍然需要Redux。除此之外，Redux还有其他相关的库，比如Redux -persist，它允许你在localStorage中保存/存储数据，并在刷新时补充水，这是Context API仍然不支持的。

正如@dan_abramov在他的博客中提到的，你可能不需要Redux, Redux有一些有用的应用程序，比如

Persist state to a local storage and then boot up from it, out of the box. Pre-fill state on the server, send it to the client in HTML, and boot up from it, out of the box. Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers can replay them to reproduce the errors. Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written. Maintain an undo history or implement optimistic mutations without dramatic changes to how the code is written. Travel between the state history in development, and re-evaluate > the current state from the action history when the code changes, ala TDD. Provide full inspection and control capabilities to the development tooling so that product developers can build custom tools for their apps. Provide alternative UIs while reusing most of the business logic.

有了这么多的应用程序，现在说Redux将被新的Context API所取代还为时过早。

如果你使用Redux只是为了避免将道具传递给嵌套很深的组件，那么你可以用Context API代替Redux。它正是为这个用例而设计的。

另一方面，如果你正在使用Redux做其他事情(拥有一个可预测的状态容器，在组件之外处理应用程序的逻辑，集中应用程序的状态，使用Redux DevTools跟踪应用程序的状态何时、何地、为什么以及如何改变，或者使用诸如Redux Form、Redux Saga、Redux Undo、Redux Persist、Redux Logger等插件)，那么你绝对没有理由放弃Redux。Context API没有提供任何这些。

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

参考:

Redux还没死! 你可能不需要Redux React钩子取代Redux吗?

我更喜欢使用redux和redux-thunk进行API调用(也使用Axios)并将响应分配给reducers。它是干净的，容易理解。

Context API对于React -redux部分的React组件如何连接到存储是非常特定的。对于这一点，反应-还原是很好的。但是如果你想，因为Context是官方支持的，你可以使用Context API而不是react-redux。

所以，问题应该是上下文API vs react-redux，而不是上下文API vs redux。而且，这个问题有点固执己见。由于我熟悉react-redux并在所有项目中使用它，我将继续使用它。(我没有动力去改变)。

但是如果你今天才开始学习redux，而且你还没有在任何地方使用过它，那么就有必要尝试一下Context API，用你的自定义Context API代码替换react-redux。也许那样更干净。

就我个人而言，这是一个熟悉程度的问题。没有明确的理由选择其中一个而不是另一个，因为它们是等价的。在内部，react-redux使用Context。

对我来说，使用Redux的唯一原因是:

你需要一个全局状态对象(出于各种原因，比如可调试性、持久性……) 你的应用程序现在或将来会很大，并且应该扩展到许多开发人员:在这种情况下，你可能需要一个间接级别(即事件系统):你触发事件(在过去)，然后你的组织中你不认识的人实际上可以听到它们

你可能不需要整个应用的间接级别，所以混合使用样式，同时使用本地状态/上下文和Redux是很好的。

If you need to use middleware for various purposes. For example logging actions, error reporting, dispatching other requests depending on the server’s response, etc. When data coming from multiple endpoints influence single component/view. When you want to have greater control over actions in your applications. Redux enables tracking actions and data change, it greatly simplifies debugging. If you don’t want server response to directly change the state of your application. Redux adds a layer, where you can decide how, when and if this data should be applied. The observer pattern. Instead of creating multiple publishers and subscribers across the whole app, you just connect components to Redux store.

何时使用Redux?