有 setState 和 Provider，使用它您可以轻松、整齐地管理您的状态，那么为什么是 Riverpod？，我在此处的输入链接描述中看到不同的示例，其中使用了 Riverpod，我只是发现每个示例都使简单的事情变得更加复杂，当如果您使用 Riverpod，则可以使用 Provider 更轻松地完成相同的操作，或者仅使用 setState 并在管理代码中的状态时遵循一些好的技术。
有一个名为 hooks_riverpod 的包，我找不到这个包的理由只是为了支持 Riverpod 你破解了所有 statndard 小部件，尽管还有另一个版本 flutter_riverpod 但使用 hooks 不是一种预期的方法，可能对来自 Reactjs 背景的人有帮助，但是flutter 工程师并没有以这种方式设计 flutter，使用这些非标准方法，你只是将自己困在这几个包的摆布中。
继承的小部件只是 flutter 提供的跨应用程序、Provider 和其他一些包（如 Redux）管理状态的标准方法，它们只是遵循相同的方法。
如果您可能使用过 Riverpod 或相关软件包，请分享您的经验。
嗯，关于良好的状态管理解决方案存在很多争论。
但针对您的情况，我想提几点。
嗯，Riverpod 的构建是为了解决 Provider 中无法解决的一些问题。喜欢：
和其他...有关更多信息，您可以在这里参考 Riverpod 的主页
此外，Riverpod & Provider 的创建者 Remi 建议使用 Riverpod 而不是 Provider。
好吧，您无法仅使用具有适当编程标准的 setState 来构建特色应用程序。您必须使用 Prop Drilling 在应用程序中连续传递数据。想象一下，一个父窗口小部件下有 5 个窗口小部件，并且父窗口小部件需要第 5 个子窗口小部件中的数据。这只是一个正常情况，在实际应用中情况可能会更糟。
嗯，是的，React 开发人员很容易快速转向 Flutter。但它的开发目的并非如此。其主要目的是使用可重用的功能小部件。因此，一个很好的例子就是，当您使用动画控制器并且每次使用它时都必须维护其生命周期。我无法在这里深入讨论，因为您可以参考文档。
这取决于项目以及您喜欢如何处理状态。如果您可以使用 setState 管理/继承小部件，则无需使用其他小部件。
我喜欢在这里分享一些参考，在Riverpod 文档第二部分你可以找到
Provider，没有其限制 Riverpod 受到 Provider 的启发，但解决了一些关键问题，例如支持同一类型的多个提供商；等待异步提供者；从任何地方添加提供商，...
riverpod, 仅飞镖（无颤动）
flutter_riverpod，使用 Riverpod 与 flutter 的基本方法。您主要将其用于状态管理。
如果您使用 hook widgets( flutter_hooks) 来减少像 dispose 这样的样板代码，您可以使用hooks_riverpod
此外，所有这些包均由同一作者Remi Rousselet提供