上下文状态可以是一个可观察的和更新的组件，它们像观察者模式一样订阅。
如果您需要组件中的上下文状态，只需订阅特定的上下文即可。
为什么我们需要在应用程序的根目录下呈现上下文提供程序，以便在其他地方使用它？
我问，因为我看到许多库和应用程序现在使用上下文作为组件之间共享状态的主要方式，但我不理解在应用程序的根目录下呈现提供者的必要性，因为每个共享状态(上下文(都可以在呈现函数之外初始化
我制作了一个npm包，它做了类似的事情，以简化应用程序的上下文/共享状态，作为的一个例子
https://www.npmjs.com/package/jstates以及用于react绑定的包https://www.npmjs.com/package/jstates-react
原因是IMHO是recat试图遵循一个没有全局状态的范式。一般情况下，您希望州尽可能是本地的。这允许进行更好的测试，您可以轻松地将mock状态输入到提供程序中。
如果你有一个全局对象，每个人都订阅它，那么就不清楚状态来自哪里。通过上下文提供程序，它非常清楚，状态被封装在组件树中(没有全局对象(。
Context API必须支持同一个上下文提供程序的多个实例(例如，在将项目的一部分迁移到某个库的新版本时(。
即使使用Context的库通常被用作singleton(用于管理全局状态(，当在React中思考时，作者需要支持可组合组件，而不仅仅是全局singleton。React API设计在可行的情况下也更喜欢组件而不是其他模式(例如<Suspense />和<Provider />，但不是生命周期挂钩(。
在设计对多个实例的支持时，为了更容易调试(更多的约束==更少可能出错的事情(，建议使用一些控制反转模式。
因此，React Components树中的显式可见性是首选的(请注意，即使是生命周期方法和钩子在树节点的详细信息中也是可见的，但您只需要查看单个节点的方法和钩子，而不需要识别"所有可以访问此上下文的子节点"(。