个人已经在不同的项目中使用了这三种策略。我必须说，在我看来，选项1在现实生活中是最可行的。以我的经验，破坏hashCode（）/ equals（）一致性会导致许多疯狂的错误，因为每次将最终结果添加到集合中之后，相等性的结果都会改变。
但是，还有其他选择（也各有利弊）：
a）基于一组不可变的，非null，分配的构造函数，字段的hashCode /等于
（+）所有三个条件均得到保证
（-）字段值必须可用于创建新实例
（-）如果必须更改其中之一，会使处理变得复杂
b）基于由应用程序（在构造函数中）而不是JPA分配的主键的hashCode /等于
（+）所有三个条件均得到保证
（-）你无法利用DB序列之类的简单可靠的ID生成状态
（-）如果在分布式环境（客户端/服务器）或应用程序服务器群集中创建新实体，则会很复杂
c）基于实体构造函数分配的UUID的 hashCode /等于
（+）所有三个条件均得到保证
（-）UUID生成的开销
（-）可能会使用两次相同的UUID，这有一点风险，具体取决于所使用的算法（可由数据库上的唯一索引检测到）
