你需要一个BuildContext才能访问你的对象，这使得它无法从业务层面进行访问。
从技术角度讲，不存在不需要BuildContext的状态管理。
在Flutter中，一个小部件并不是独立存在的。一个Widget伴随着一个Element。这个Element维护着小部件在小部件树中的位置。如果该元素被挂载，那么小部件就存在于小部件树中。当该元素被卸载时，小部件将永久地从小部件树中移除。Element包含了一些函数，比如update、rebuild、performRebuild、updateChildren以及其他许多函数，这些函数被框架用于管理小部件的生命周期和内部行为，用于更新状态以及许多其他功能。您总是需要这个Element来更新相应Widget的状态。无论是StatelessWidget还是StatefulWidget都使用这个元素进行重新渲染。
惊喜，惊喜，Element实际上是framework.dart中BuildContext的一个实现。
我知道你的意思是使用BuildContext来检索表示状态的对象。这更多是一个设计选择，而不是包作者必须做出的技术要求。基本上，您正在使用上下文获取与相应小部件树分支相关联的状态对象实例，由某个父小部件。就是这样。您这样做，而不是传递表示状态的类实例给子小部件的另一种方法。这两种方法都是“可以”的状态管理方法。
仅仅使用上下文来进行状态管理，这在我看来是一个糟糕的设计决策。我个人认为每次都使用上下文来实现状态管理非常繁琐。在许多情况下，我见过无数应用程序只实例化一次控制器或ChangeNotifier，并将其注入到根级别小部件中。基本上只使用一个实例。使用BuildContext的一个主要目的是您可以为多个子元素提供多个实例，从而区分它们的行为。但现实情况是，绝大多数应用程序不需要此功能。使用Context的另一个好处是，您可以动态地检索对象实例（控制器、ChangeNotifiers等），例如Provider.of<MyClass>(context)，而无需一直传递它们。本质上，这是依赖注入的一个示例。但这更像是一个糟糕的设计决策，而不是伟大的技术成就，因为您的类实例的来源是模糊的。您只知道实例的类型。但最终，一切都是个人偏好，如果您正在工作，则通常由管理您的人决定使用什么架构和状态管理解决方案。有使用所有这些“正确”状态管理方法编写的应用程序。
