Flutter BLoC变量存储最佳实践：存Bloc类还是State类？

方案1：变量直接声明在BLoC类内部 #

状态稳定性问题 #

• 完全不符合BLoC 单向事件驱动数据流 的设计规范，存在严重的状态一致性风险：可变变量的修改不会触发状态更新通知，UI层通过BlocProvider.of拿到的是最新值，但BlocBuilder绑定的状态还是旧值，会出现同页面不同位置取值不一致的问题。
• 无状态变更回溯能力：变量变更没有记录在状态流中，开发调试时无法通过BLoC devtools查看变更历史，出现问题很难定位根因。
• 存在竞态隐患：如果有多个异步事件同时修改该变量，没有统一的状态emit机制做顺序管控，最终值完全不可预期。

性能问题 #

• 额外的不必要开销：如果要让UI感知变量变更，需要手动实现监听逻辑，远不如官方原生的状态刷新机制高效；如果没有做值变更校验，还容易触发无意义的UI重绘。
• 若BLoC生命周期较长，可变变量长期驻留内存没有自动重置机制，页面复用的时候容易读到脏数据，额外增加清理逻辑的开销。

方案2：变量作为State类属性存放 #

状态稳定性表现 #

• 这是BLoC官方推荐的标准实现，完全符合单向数据流规范：State本身是不可变对象，所有变更只能通过emit新State实例触发，不存在状态不一致的问题。
• 配合Equatable的props校验机制，可以确保每一次状态变更都是可追溯、可预测的，devtools可以完整展示所有状态变化历史，调试成本极低。

性能表现 #

• 官方原生做了深度优化：Equatable的属性比对开销极小，只有当props中绑定的属性真实发生变化时，才会触发BlocBuilder的重绘，性能完全可控，没有多余的性能损耗。

最终建议 #

只有完全不需要UI感知、仅在BLoC内部使用的临时变量（比如请求取消令牌CancelToken、防抖定时器Timer等）可以放在BLoC类内部声明，所有和UI展示、业务逻辑状态相关的变量，必须存放在State类中。

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