Flutter开发中能否用Bloc存储全局应用数据？是否需搭配SharedPreferences？

全局ApplicationBloc的用法判定 #

你提出的在main入口挂载全局ApplicationBloc、各页面维护独立Bloc的分层设计，本身就是Bloc生态官方推荐的全局状态实现方式，和你之前在React Native中使用根挂载Redux全局Store的逻辑完全对齐，用法没有问题。
所有挂载在根节点下的子页面，都可以通过context.read<ApplicationBloc>()获取全局Bloc实例，读写跨页面共享数据，和React Redux中通过connect方法消费全局Store的逻辑完全等价。
需要补充两个实践注意点：

• 版本API适配：如果你使用的是bloc7.0.0及以上的版本，原bloc:参数写法已经废弃，推荐通过create回调实例化Bloc，自动完成依赖注入和内存回收逻辑，避免手动管理Bloc实例的泄漏风险，适配后的写法参考：

void main() => runApp(
  BlocProvider<ApplicationBloc>(
    create: (context) => ApplicationBloc(),
    child: MyApp(),
  ),
);

• 状态边界划分：全局ApplicationBloc只适合存储和应用生命周期一致、跨多页面共享的数据，比如购物车商品列表、全局登录态、用户基础信息、全局主题配置等；单页面独有的状态（比如页面表单输入、分页加载状态、局部弹窗开关）依然交给页面专属Bloc管理，不要把所有状态都堆到全局Bloc里，否则很容易导致全局状态臃肿、耦合过高难以维护。

应用级数据持久化的方案选择 #

存储用户这类应用级数据，完全不是必须使用SharedPreferences，它只是轻量键值存储的一个可选实现，你可以根据存储的数据类型、体量自由选择适配方案，所有方案都可以和Bloc无缝衔接：

• SharedPreferences：最适合存体积极小的简单键值对，比如用户登录token、主题偏好开关，集成成本最低
• Hive：纯Dart实现的轻量NoSQL存储，不需要原生通道依赖，适合存结构稍复杂的集合类数据，比如购物车的商品列表，读写速度远高于SharedPreferences
• Drift/SQLite：适合需要结构化查询、数据量较大的场景，比如离线商品缓存、用户浏览历史等
• 原生文件序列化：如果你的Bloc状态本身是可JSON序列化的结构，也可以直接通过dart:io把状态序列化后写入应用文档目录，不需要引入任何第三方依赖

实际落地的时候，只需要在ApplicationBloc初始化阶段从本地存储加载缓存数据作为初始状态，在Bloc的状态变化回调里把更新后的状态同步写入本地存储即可，这套逻辑和具体选用哪种持久化方案没有强绑定关系。

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