让Cubit监听StreamController是否为不良实践？是否应改用Bloc？

这种做法算不算不良实践？ #

算不上典型的不良实践，但有不少可以优化的点：

• StreamController<void>只通知“有变更”却不传递具体数据，导致Cubit每次都要调用refreshSpots()拉取全量数据，数据量大时会有性能浪费。如果能把变更的具体内容（比如新增/修改/删除的条目）通过Stream传递，Cubit就能针对性更新状态，效率会高很多。
• 一定要做好StreamSubscription的生命周期管理：必须在Cubit的close()方法里取消_occupancySubscription，否则会造成内存泄漏。示例代码：

@override
Future<void> close() {
  _occupancySubscription?.cancel();
  return super.close();
}

• 单例模式的DataRepository如果处理不当，容易出现多页面状态共享干扰的问题，要确保单例的初始化、销毁逻辑足够可靠。

是否更适合使用Bloc？ #

不一定，得看业务场景复杂度：

• 如果你的业务逻辑只是响应数据变更触发刷新，Cubit完全够用，它的API更简洁，学习和维护成本更低。
• 要是后续业务逻辑变复杂，比如需要处理多种事件（手动刷新、筛选数据、批量操作等），且状态转换需要更清晰的事件-状态映射关系，那Bloc的Event-State模型会更合适，能让逻辑结构更清晰、更易扩展。
• 另外Bloc本身也支持Stream监听，你可以把Supabase的实时流直接接入Bloc的事件处理逻辑中，写法和Cubit类似，但规范性更强。

优化建议（基于Cubit的方案） #

如果想保留Cubit的实现，可以做这些优化：

• 让Stream传递具体的变更事件，而非空的void，比如定义一个包含变更类型和数据的类：

enum ChangeType { add, update, delete }

class DataChangeEvent {
  final ChangeType type;
  final Spot data;

  DataChangeEvent(this.type, this.data);
}

// 仓库里的StreamController也对应修改
final StreamController<DataChangeEvent> _dataChangeController = 
    StreamController<DataChangeEvent>.broadcast();
Stream<DataChangeEvent> get onDataChanged => _dataChangeController.stream;

• Cubit监听时根据具体事件更新状态，避免全量刷新：

_occupancySubscription =
    _dataRepository!.onDataChanged.listen((event) {
  // 根据变更类型和数据，针对性更新现有状态里的spots列表
  updateSpots(event);
});

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