用途：整理 Riverpod 的常见问题与最佳实践，帮助开发者正确使用 provider、Ref 与 WidgetRef，避免常见陷阱。
主要能力与要点：
- ref.refresh 与 ref.invalidate：refresh 等于 invalidate 加 read，会失效并返回新值；不需要新值时用 invalidate，需要立即拿到结果时用 refresh。单独 invalidate 后重算可能发生在下一帧或下次读取时。
- Ref 与 WidgetRef 不共享接口是刻意设计，避免写出同时依赖两者的代码；建议把逻辑放进 Notifier，从 UI 调用 ref.read(notifierProvider.notifier).yourMethod()。
- 使用 ConsumerWidget 而非 StatelessWidget：InheritedWidget 与 BuildContext 无法支持 ref.listen 这类变更监听，也无法感知停止监听（auto-dispose、family 需要），因此 Riverpod 需要不绑定 BuildContext 的 Ref。
- hooks_riverpod 不导出 flutter_hooks，是为了让各包独立版本化。
- 没有一次性重置所有 provider 的 API，这被视为反模式；登出清状态应让依赖当前用户的 provider 去 watch 用户 provider，用户变化时依赖项重算或清空。
- 组件即将或已卸载时使用 ref 不安全：在 await 之后使用 ref 前应检查 if (!context.mounted) return;。
Do / Don't：避免在组件中初始化 provider，provider 应自行初始化；避免用 provider 存临时状态（选中项、表单、动画、控制器类状态），局部状态用 flutter_hooks 或本地状态；不要在 provider 初始化时执行副作用，provider 应代表读操作，写操作使用 mutations；优先使用静态已知的 provider 配合 ref.watch/read/listen；避免动态创建 provider，应定义为顶层 final 变量。可启用 riverpod_lint 强制这些实践。
限制：资料未提供具体安装命令、版本要求或完整代码示例；部分主题（如 riverpod-mutations、riverpod-getting-started）仅被引用，未展开细节。