Java多字段场景下equals与hashCode方法的使用疑问

1. 考虑Hibernate对象状态，不在equals和hashCode中使用id是否为最佳实践？ #

是绝对的最佳实践。Hibernate中的对象有三种状态：瞬时态（刚创建未入库，id为null）、持久态（已入库，id存在）、游离态（已脱离Session但id存在）。如果用id实现equals/hashCode，会出现以下问题：

• 瞬时态对象的id都是null，两个属性完全相同的新对象会被判定为不相等，违背业务预期。
• 把瞬时态对象放进集合（比如HashSet）后，一旦入库生成id，对象的hashCode会突变，导致集合无法正确找到该对象，引发查找、删除失败的问题。
  所以正确的做法是基于业务层面的唯一标识字段实现，这类字段在对象创建时就会被赋值，不受Hibernate状态影响。

2. 当类中存在非id的唯一字段时，仅使用其中一个实现equals和hashCode是否足够？ #

完全足够，但有个核心前提：这个字段必须是业务上不可变的唯一键。比如用户的手机号、邮箱（如果业务规则明确唯一且不允许修改），只用这一个字段就能精准区分对象。
这么做的好处是实现简单、性能更高，而且避免了多字段组合可能带来的维护问题。但要注意，如果这个字段是可变的（比如允许用户修改手机号），那修改后对象的hashCode会变化，放进集合后同样会出现查找异常，这种情况就不能只用它，得换不可变的唯一字段。

3. 当类中除id外无其他唯一字段时，是否应添加除id外的所有字段？还是仅添加数值字段而非文本字段？ #

首先要明确：这种情况属于业务设计的缺陷，尽量要避免——没有业务唯一键的实体，在业务逻辑中很难准确区分，后续会引发各种问题。如果实在要处理，遵循以下原则：

• 绝对不要用所有字段：大部分业务字段是可变的，修改后equals/hashCode会变化，导致集合操作（比如HashSet、HashMap）出现异常。
• 不要只挑数值字段：数值字段同样可能被修改，而且没有逻辑支撑这种选择，纯粹是自欺欺人。
• 正确做法：找业务上能唯一标识对象的最小不可变字段组合——这些字段在对象创建后就不会被修改。如果连这样的字段组合都没有，只能退而求其次：equals中先判断id是否存在，存在则用id比较；不存在则比较对象引用（即==）。但这种方式会导致瞬时态对象只能和自身相等，业务上可能不符合预期，所以还是建议优先优化业务设计，补充业务唯一键。

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