Riverpod：build方法用ref.read为不良实践？同是按钮触发为何有别？

核心原因在于**ref.read和ref.watch的本质差异**，以及Riverpod对Widget生命周期、状态同步的设计逻辑：

先明确两个API的核心区别 #

• ref.watch(provider)：会与provider建立监听关系，当provider的状态/实例发生变化时，当前Widget会被触发重建，始终获取最新的provider实例或状态。
• ref.read(provider)：仅一次性获取provider的当前值/实例，不会建立任何监听，后续provider更新时，不会通知当前Widget。

案例1（不良实践）的问题 #

在build方法里调用ref.read(counterProvider.notifier)，存在两个关键问题：

1. 状态同步风险：如果counterProvider.notifier后续被重新创建（比如provider依赖的其他状态变化导致它重建），build方法不会感知到这个变化，onPressed里持有的还是旧的StateController实例，点击按钮修改的是旧实例的状态，会和实际provider的状态脱节，出现状态不一致的bug。
2. 违反设计规范：build方法会被Flutter频繁调用（比如父组件重建、屏幕旋转、主题切换等场景），ref.read的设计初衷是用于一次性操作（比如点击事件、异步回调这类非build阶段的逻辑），在build里使用它会破坏Riverpod的监听机制，容易引发难以排查的状态问题。

案例3（良好实践）的合理性 #

在build方法里用ref.watch(counterProvider.notifier)，完全契合Riverpod的设计：

• 当counterProvider.notifier发生任何变化时，Widget会自动重建，获取最新的StateController实例，保证onPressed里的实例始终是最新的，不会出现状态不同步的问题。
• 虽然这里StateProvider的notifier一般不会轻易变化，但遵循规范使用ref.watch能确保代码在复杂场景下的健壮性，比如后续修改provider类型（换成ChangeNotifierProvider等）时，代码依然能正确工作。

补充：案例2的合理性 #

案例2把ref.read放在onPressed回调里，这也是正确的——因为点击事件是一次性触发的操作，不需要监听provider变化，只是在点击时获取当前最新的notifier实例修改状态，完全符合ref.read的使用场景。

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