StateProvider的listen与watch有何区别？watch与read使用疑问

首先定义一个基础的StateProvider：

final valueStateProvider = StateProvider<int>((ref) => 50);

两种弹窗触发写法的核心区别 #

1. 触发逻辑与时机差异 #

• ref.listen搭配watch的写法：

  Widget build(BuildContext context, WidgetRef ref) {
    final value = ref.watch(valueStateProvider);
    ref.listen<int>(valueStateProvider, (prev, curr) {
      if (curr == 65) {
        ScaffoldMessenger.of(context).showSnackBar(
          const SnackBar(content: Text('Value is 65')),
        );
      }
    });
    // ...其他Widget代码
  }
  

  这种写法聚焦状态的变化过程：只有当状态从「非65」更新为「65」时，才会触发SnackBar。它只关注状态的变更动作，只会在状态满足“从旧值到新值的变化符合条件”时执行一次逻辑，不会因为Widget的重复重建而触发。

• 直接在build中watch判断的写法：

  Widget build(BuildContext context, WidgetRef ref) {
    final value = ref.watch(valueStateProvider);
    if (value == 65) {
      ScaffoldMessenger.of(context).showSnackBar(
        const SnackBar(content: Text('Value is 65')),
      );
    }
    // ...其他Widget代码
  }
  

  这种写法聚焦当前状态的值：只要当前状态是65，每次Widget rebuild时都会弹出SnackBar。比如页面因父组件重建、其他状态更新等原因触发build时，只要value仍为65，就会重复执行弹窗逻辑，造成不必要的重复触发。

2. 与Widget生命周期的绑定关系 #

• ref.listen的回调和Provider的状态变化强绑定，和Widget的build周期解耦，只有状态真的发生符合条件的变化时才会执行。
• 直接在build中判断的逻辑和Widget的build周期强绑定，每次build都会执行判断，无论状态是否有变化。

为什么用watch而非read？ #

• ref.read的局限：ref.read()只会一次性获取Provider的当前值，不会订阅后续的状态变化。如果用read替代watch，当valueStateProvider的状态从50更新为65时，Widget不会感知到这个变化，不会触发重建，自然也不会执行任何和新值相关的逻辑。
• ref.watch的作用：ref.watch()会订阅Provider的状态变化，当状态更新时自动触发Widget重建，确保能拿到最新的状态值。不管是搭配listen使用，还是直接在build中判断，都需要Widget能感知到状态的变更，所以必须用watch来维持状态的订阅关系。

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