Flutter Bloc：operator==与const构造函数的区别及选择探讨

这事儿核心是const构造的适用场景太窄，没法覆盖Bloc里所有状态/事件的比较需求，具体原因如下：

• 不是所有状态/事件都能加const构造
  Bloc的状态经常需要包含动态数据，比如用户输入的字符串、服务器返回的时间戳（DateTime类型）、或者运行时计算的值。这些类型根本没法作为const构造的参数——const要求所有成员都是编译时常量。比如给Person加个final DateTime birthDate，const Person(name: "张三", birthDate: DateTime.now())直接报错，因为DateTime.now()是运行时才确定的值。这种场景下，const构造完全用不了，只能靠operator==来做值比较。

• const构造只认编译时单例，不认值相等
  看你第一个代码示例，两个const Person(name: "Alice")确实是同一个实例，==会返回true。但如果是运行时动态创建的实例（比如用户点击按钮后生成的事件），哪怕值完全一样，默认的==是比较对象引用，结果就是false：

  final p1 = Person(name: "Alice"); // 没加const
  final p2 = Person(name: "Alice");
  print(p1 == p2); // 第一个示例输出false，第二个实现operator==的示例输出true
  

  Bloc判断是否需要更新状态，全靠比较新旧状态的==结果。如果同值不同引用的状态被判定为不相等，Bloc会触发不必要的UI刷新；反过来如果该更新的时候没识别到，又会导致UI不更新。所以必须靠自定义的operator==来保证值相等就返回true，不管是不是同一个实例。

• 继承场景下const的限制更多
  像你第一个示例里Person继承了带const构造的PersonBase，但如果后续子类需要添加非const成员，或者基类有其他非const的子类，const的优势就彻底没了。而实现operator==是更灵活的方案，不管继承层级怎么变，只要正确实现所有成员的比较逻辑，就能保证比较的准确性。

• 手动写operator==容易出错，辅助包更省心
  手动实现operator==和hashCode很容易漏写成员变量，或者hashCode计算错误，导致比较逻辑出问题。像equatable这类辅助包能自动生成这些代码，既减少重复劳动，又能避免人为失误。而且就算你用了const构造，辅助包也能兼容，相当于多一层保障。

对比你给出的两个代码示例：

• 第一个用const构造的版本，只有const创建的同值实例才会被判定为相等；非const创建的同值实例会被当成不同对象。
• 第二个实现operator==的版本，不管实例是怎么创建的，只要name相同就判定为相等，这才是Bloc状态比较需要的核心逻辑——值相同就认为状态没变化，不需要更新。

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