有很多 Flutter 状态管理方法 https://flutter.dev/docs/development/data-and-backend/state-mgmt/options
为了避免固执己见的回应，有人可以提供具体的例子来支持为什么state management approach that doesn’t need a BuildContext是"坏"或"危险信号">
在没有 BuildContext 的情况下使用状态管理包的一个参数是：
事实上，你需要一个BuildContext来访问你的对象，这使得它 无法从业务层访问。
从技术上讲，没有不需要BuildContext的状态管理。
小部件本身在 Flutter 中不存在。Widget伴随着Element。Element保持小部件在小部件树中的位置。如果元素已挂载，则小部件存在于小部件树中。卸载元素后，它会从小部件树中永久删除。该Element包含诸如update，rebuild，performRebuild，updateChildren等函数，以及框架用来管理小部件的生命周期和底层行为，更新状态和许多其他功能的功能。您始终需要此Element来更新相应Widget的状态。StatelessWidget和StatefulWidget都使用此元素重新呈现。
令人惊讶的是，Element实际上是在framework.dart中看到的BuildContext的实现
。我知道你的意思是使用BuildContext来检索代表状态的对象。这更像是一种设计选择，而不是包作者必须提出的技术要求。本质上，您正在使用上下文来获取由某个父小部件关联的状态对象实例。就是这样。您正在这样做，而不是将表示状态的类实例传递给子小部件的其他方法。两者都是状态管理的"OK"方法。
老实说，在我看来，仅限于使用上下文是一个糟糕的设计决策。我个人认为，每次都使用上下文来整合状态管理，这简直是潮汐。在许多情况下，我见过无数的应用程序，它们只实例化控制器或 ChangeNotifier 一次，并将其注入根级小部件。基本上只使用一个实例。使用 BuildContext 的一个主要目的是，您可以为多个子级数组提供多个实例，从而区分它们的行为。但现实情况是，绝大多数应用程序不需要此功能。使用上下文的另一个好处是，您可以像Provider.of<MyClass>(context)一样动态地检索对象实例(控制器，更改通告器等)，而无需一直传递它们。从本质上讲，这是依赖注入的一个例子。但这更像是一个糟糕的设计决策，而不是伟大的技术壮举，因为类实例的来源是模棱两可的。您只知道实例的类型。但归根结底，一切都是个人喜好，如果你在工作，通常由管理你的人来决定使用哪种架构和状态管理解决方案。有些应用使用所有这些"正确"的状态管理方法编写。
顺便说一下，你可以签出涡轮增压器。这是我创建的一种非常简单有效的状态管理方法，它不使用上下文来维护和更新状态，至少现在还没有。它还具有最简单的事件系统之一，以便仅将您的小部件订阅到特定事件。