我错了，还是我们只想将一个值传递到Widget树上，Provider只是一个带有dispose方法的InheritedWidget？
是的。提供程序确实主要是基于继承小部件的功能。
如果你想自己做，那很好。但是你很快就会意识到，如果没有提供者，你将有数百个无用的重复行。
提供程序基本上采用 InheritedWidgets 的逻辑，但将样板减少到严格的最低限度。
Provider不是必须的，但应该。
首先，它由 Flutter Team 推广，并且足够灵活，可以处理几乎任何状态管理解决方案。
说InheritedWidgetdispose可能不公平，因为Provider有太多不同的用例，并且继承了一些你可能在其他任何地方都找不到的优化。
如果在大型应用程序中使用InheritedWidget，build方法始终会重新生成整个生成方法。但是有了Provider你就有了Consumer小部件，它可以非常具体地控制build方法的特定块，所以你有更高的效率。此外，侦听器的复杂性低于 InheritedWidgets'(O(N) vs O(N²))。
问题在于，由于 Flutter 最初旨在成为一个 UI 框架，因此默认的状态管理解决方案也是面向 UI 的。
最后，由于不同的项目需要不同的状态管理模式，因此一个打包方案是非常宝贵的 imo。
Flutter 文档有一个很好的部分，他们谈论的是应用程序中的状态管理(其中很大一部分是将值传递到树下)。
Flutter 具有小部件为其后代提供数据和服务(换句话说，不仅仅是它们的子项，还有它们下面的任何小部件)提供数据的机制。正如您对 Flutter 所期望的那样，其中一切都是 Widget，这些机制只是特殊类型的小部件——InheritedWidget™、InheritedNotifier、InheritedModel 等。我们不会在这里介绍这些内容，因为它们对于我们尝试做的事情来说有点低级。
相反，我们将使用一个与低级小部件一起使用但易于使用的包。它被称为提供者。
因此，截至 2021 年底，似乎建议使用provider包，除非您需要较低级别的访问权限 - 在这种情况下，您可以使用Inherited*小部件。 例如，如果您编写了自己的provider版本，则需要较低级别的访问权限。
我上面引用的文档在 https://docs.flutter.dev/development/data-and-backend/state-mgmt/simple#accessing-the-state