Flutter Bloc仅使用单个State类是否存在性能等弊端？

大体积待办列表强制克隆会不会造成严重资源浪费？ #

绝大多数常规业务场景下完全不会产生需要重点关注的资源浪费，只有极端错误的实现才会引发性能问题。

• 很多人对“克隆状态”有误解：常规的copyWith实现对列表这类引用类型字段，只会传递原列表的引用，不会遍历深拷贝列表里的每一条待办数据。这种情况下哪怕列表里存了几万条数据，克隆一个状态实例的开销也只是多存几个内存地址，耗时在微秒级，远低于Flutter单帧的渲染预算，用户根本感知不到。
• 真正会产生大额开销的是错误的深拷贝逻辑：如果你在写copyWith的时候手动写了全量遍历复制每一个Todo对象的代码，才会出现列表越大拷贝越慢的问题，这种写法本身就不符合不可变状态的最佳实践，未修改的字段直接传原引用即可，不需要全量重建。
• 至于加载状态下的“无意义克隆”更不存在：加载状态下todos字段本身就是空值或者上次留存的引用，根本不会触发大对象的复制操作，所谓的“强制执行克隆浪费资源”本质是把引用传递和深拷贝的概念搞混了。

拆分独立状态子类是不是比单State类方案更优？ #

两种方案都是Bloc生态认可的标准实现，没有绝对的优劣，只看业务场景适配度：

单State类搭配状态枚举的方案（官方示例常用写法） #

• 优势：开发维护成本低，不需要定义大量子类，所有状态字段统一管理，copyWith逻辑集中，UI层只需要读取状态枚举值就能判断当前渲染逻辑，不容易出现类型转换错误。
• 劣势：确实存在少量字段冗余，比如加载状态下待办列表、筛选条件这类字段暂时不会被用到，但这点内存开销完全可以忽略，完全到不了需要优化的程度；如果状态字段特别多，copyWith方法会写的比较冗长。

拆分Initial/Loading/Success/Error等独立子类的方案（一般用Dart密封类实现） #

• 优势：类型安全性更强，UI层用switch匹配状态时，Dart的静态检查会强制覆盖所有状态分支，不会出现漏判状态的bug；每个状态子类只需要存自己需要的字段，完全没有冗余，比如TodoOverviewLoading状态可以只存加载提示字段，根本不需要携带待办列表数据。
• 劣势：样板代码量更大，每新增一种状态就要新建一个类，跨状态传递公共数据（比如从加载中切到成功时要携带之前用户选的筛选条件）需要手动传值，漏传很容易出业务bug。

实际选型建议：如果是中小型业务场景，状态逻辑不复杂，直接用单State类加枚举的方案就行，开发效率最高；如果是复杂业务模块，状态分支多、不同状态下的字段差异极大，用密封类拆分子类的方案更稳妥，能减少很多状态判断相关的bug。不用为了所谓的“克隆性能开销”强行选某一种方案，两种写法在正确实现的前提下性能没有本质差别。

内容的提问来源于stack exchange，提问作者Thịnh Hà