Flutter使用Riverpod做状态管理时，修改UsuarioProvider状态未生效仍显示初始值

• Provider 作用域定义错误，状态链路完全隔离
  你将 usuarioProvider 的声明写在了持有BuildContext的组件局部作用域内部，而非文件全局顶层位置。这种写法会在每次所在的build方法执行时，生成一个全新的独立Provider实例：触发状态变更时用到的Provider、Consumer组件监听的Provider，是两个完全隔离的不同对象，哪怕你调用了状态修改方法，Consumer监听的永远是它对应实例的初始硬编码值，自然拿不到更新后的邮箱。
• 本地存储读写逻辑完全失效
  • 自写的 recibirEmailSP 方法仅从SharedPreferences中取出了email值，但既没有把读到的结果赋值给state，也没有返回这个值，属于完全无效的逻辑；同时UsuarioProvider的构造函数从来没有调用过这个方法，应用启动时永远会用硬编码的"No user"做初始状态，不会读取本地已存的历史邮箱。
  • cambiarEmailUsuarioSP 存在冗余逻辑：在cambiarUsuario方法开头已经给state赋了新值，这个异步方法里又重复给state赋值；且调用这个异步方法时没有加await，也没有任何错误捕获，一旦SharedPreferences写入失败，整个链路没有任何兜底处理。
• 状态监听写法存在兼容问题
  你在Consumer中使用watch(usuarioProvider.state)的写法，在非全局的Provider作用域下会进一步放大实例不匹配的问题；同时这种写法在新版本Riverpod中已被标记为废弃，正确的监听逻辑是直接watch Provider本身，即可拿到对应的状态值。

• 把 usuarioProvider 的声明从局部作用域移到文件全局顶层位置，保证整个应用内所有组件拿到的是同一个Provider实例
• 调整UsuarioProvider的初始化逻辑：在Provider的创建回调里，先通过异步方法读取SharedPreferences中存储的历史邮箱，再把读到的值作为StateNotifier的初始状态，不要在构造函数里硬编码初始值
• 所有涉及SharedPreferences的异步操作加await，删除重复的state赋值逻辑，为SP读写补充基础的错误捕获
• Consumer中监听状态时直接写watch(usuarioProvider)，无需额外拼接.state后缀

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