使用RiverPod时是否需摒弃setState改用StateNotifierProvider

不存在必须把所有状态都塞进StateNotifierProvider的硬性规则，两者是互补关系，按场景选方案就好

• 纯局部、无共享需求、逻辑极简单的临时UI状态，优先用setState
  这类状态的生命周期完全和当前Widget绑定，不需要跨组件访问，也没有复杂变更逻辑，用setState是成本最低的实现，比如：
  • 按钮点击后自身的加载/可点击状态切换
  • 输入框聚焦时的样式临时变更
  • 组件内部折叠面板的展开/收起状态
  • 单页面内不涉及其他组件的Tab选中索引
    这类状态如果硬要抽到StateNotifierProvider里，平白多写一堆模板代码，把简单逻辑搞复杂，属于典型的过度设计。
• 符合以下特征的状态，更适合放到StateNotifierProvider中管理：
  • 需要跨多个组件/页面共享的状态，比如用户登录信息、全局购物车数据、应用主题配置，用Provider管理可以省掉层层传参的麻烦
  • 带复杂变更逻辑的状态，比如列表页的加载/空态/错误/分页多状态流转、表单的多字段校验+提交逻辑，封装在StateNotifier里可以把业务逻辑和UI代码解耦，不用搭Widget环境就能单独测试逻辑
  • 需要持久化、或者要联动其他业务逻辑的状态，比如状态变更时要触发缓存写入、日志上报、关联接口请求，统一放在Notifier里处理，比散落在各个Widget的setState调用里好维护得多
• 两者完全可以共存，没有任何冲突
  Riverpod本身就提供了ConsumerStatefulWidget这类支持本地状态的组件，从设计之初就没打算替代setState。实际开发里完全可以在同一个页面中，把局部临时UI状态交给setState管，把共享、复杂的业务状态交给Provider管，怎么顺手怎么来。

刚接触Riverpod的开发者很容易走极端，追求所谓"100%状态托管"，连个按钮的hover状态都要抽个单独的Notifier，最后代码里堆了一堆零散的小Provider，找状态、改逻辑绕半天，维护成本反而比原生写法高。判断要不要把状态放进Provider的标准非常直白：把状态抽出去之后，能不能减少重复代码？能不能方便逻辑复用？能不能降低UI和业务的耦合？如果三个问题答案都是否，老老实实⽤setState就行，硬套Provider反而是反模式。

内容的提问来源于stack exchange，提问作者Lerex