flutter-state-management

Flutter 状态管理

先明确所有权和生命周期，再选择实现机制。

检查

确定哪些状态属于临时 UI 状态、功能状态、共享应用状态、缓存的服务端数据或持久化数据。明确由谁创建、修改、观察和释放这些状态。

规则

• 在满足所有使用者需求的前提下，尽可能让状态保持局部。
• 保持单一事实来源；派生次级值，而不是同步多个副本。
• 明确状态转换，并将副作用放在 widget 的 build 方法之外。
• 如果现有 package 及其约定运行正常，就沿用它们。
• 对于新项目，应根据复杂度、团队熟悉程度、可测试性、对代码生成的接受度和生命周期需求进行选择，而不应只看流行度。
• 暴露不可变状态，或提供可变集合的只读视图。
• 当 UI 对加载、空、成功和失败状态有不同呈现时，应明确建模这些状态。
• 避免范围过广的订阅导致无关子树重建。
• 仅在 build 或其他支持 watch 的方法中使用 package 的 watch 风格访问器（ref.watch、context.watch<T>()、BlocBuilder）；在回调和事件处理程序中使用其一次性访问器（ref.read、context.read<T>()、Bloc 的 add）。在回调中调用 watch 风格访问器，在大多数 package 中会抛出异常或导致行为异常。

不要将全局服务定位器或 package 级单例作为模糊所有权问题的捷径。

验证

测试有意义的状态转换、失败恢复、释放行为和重复事件。检查高频路径的重建范围，并运行 widget 测试，验证状态到 UI 的行为。

边界

全局架构的依赖方向归 flutter-architecture 负责；持久化和远程缓存归数据领域的专门规范负责。

如果涉及释放行为或生命周期泄漏，请遵循生命周期与释放参考。对于异步状态建模和错误恢复，请遵循异步状态模式参考。

来源

• Flutter 状态管理基础