我正准备用 Flutter 和 Provider 编写我的第一个重要应用程序。我已经阅读了提供程序如何促进不可变小部件(StatelessWidgets(。我的问题是，在使用提供程序时使用 StatefulWidgets总是一个反模式吗？如果不是，在提供程序应用程序中最好使用状态小部件的示例是什么？
编辑
使用Provider已经几个月了，在任何情况下，我仍然更喜欢它而不是StatefulWidgets。我时不时地介绍一个 StatefulWidget，主要是为了熟悉它们，并且几乎立即后悔并重构到 Provider。前几天我遇到了小部件无法刷新，因为它们是相同的类型，所以正在考虑引入键以便它们会刷新。前几次尝试失败了，所以我重构到 Provider 中，一切正常(不需要键(。
反模式不是我的OP中的专有术语。我想我的问题是，是否有StatefulWidgets更干净或更容易/更好使用的例子？
provider不在乎你写的是无状态/有状态还是其他任何东西(钩子？
在许多情况下，它消除了编写StatefulWidget的需要，但它并没有声称您应该只使用StatelessWidget。
最后，你的工作是决定是否需要StatefulWidget。例如，在编写动画时可能需要它。
添加到 Rémi 的答案和这个实现的新内容：
- 将提供程序用于共享模型
- 在需要时使用小组件状态来管理特定于该问题的模型 想象一下，身份验证
- 后的用户对象，之前的 null，通过应用程序共享，具有特定于编辑字段的状态的表单，如昵称或其他什么，更新本地状态并可能传播到产品的其余部分(当后端完成更新时?...谁知道呢(，当不再需要该视图时，该状态将被释放，但用户引用仍通过提供程序引用保留。在提供程序模型中管理所有这些状态更改是没有意义的 - 这就是结果所在。
根据我在 React+Redux 方面的经验，以及在原生 Web 组件(与这两个组件相似的生命周期(以及 LitElement 中传递对象的经验，在这里做一些假设。到目前为止，这些模式看起来很相似，如果不是相同的话。
Provider.of<ProviderClass>(context, listen: false);
提供程序是 Flutter 具有的状态管理机制之一，在引擎盖下，提供程序跟踪在小部件内完成的更改。对于提供者来说，无论是无状态小部件还是有状态小部件都无关紧要，如果有任何更改，它将重建小部件。
listen: false告诉提供程序即使数据被修改，也不要重新生成小部件。这意味着只有当父小部件被 setState(( 修改或ProviderClass类值被修改时，它才能重新构建。