使用Cubit处理表单：是否需创建3个Cubit？是否存在冗余？

拆分三个Cubit的合理性 #

• 符合单一职责原则：每个Cubit只负责一个核心动作——获取主题列表、管理选中主题、处理消息发送，职责边界清晰，后续修改某一部分逻辑时，不会影响其他功能的代码，降低维护成本。
• 状态隔离更清晰：三个Cubit的状态各自独立，不会出现一个状态类里混杂多种业务状态的情况，比如主题加载的Loading状态和消息发送的Loading状态不会互相干扰，避免状态判断混乱。
• 具备复用潜力：如果后续其他页面需要调用“获取主题列表”的逻辑，这个独立的Cubit可以直接复用，无需从大Cubit中剥离代码。

合并为单个Cubit的适用场景 #

如果你的反馈表单是小型独立功能，且确定后续不会有扩展需求（比如不会新增表单字段、不会在其他页面复用主题逻辑），可以将所有逻辑合并到一个FeedbackFormCubit中：

• 设计一个复合状态类FeedbackFormState，包含三个模块的状态：
  • 主题加载状态（idle/loading/loaded/error）
  • 当前选中的主题
  • 消息发送状态（idle/sending/success/error）
• 这种方式的好处是减少文件数量，对于简单场景来说更轻便，无需管理多个Cubit的实例和监听。

结论 #

是否冗余取决于你的业务规模和扩展计划：

• 若功能简单且无扩展预期，合并为单个Cubit更高效；
• 若业务有扩展潜力，或需要复用部分逻辑，拆分三个Cubit是更合理的架构选择，不属于冗余工作。

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