java中equals方法的核心是明确业务相等语义，而非简单增加字段；需确保纯函数性、嵌套对象深度比较正确、hashcode与equals严格同步，并用单元测试验证契约。
Java 中 equals 方法处理复杂业务逻辑的判等，核心不是“加更多字段”，而是让相等语义清晰、可维护、不破坏契约。业务越复杂，越要回归本质：什么才算“逻辑上相等”？这个定义必须稳定、无歧义，并能被所有调用方一致理解。
明确业务相等的边界条件
不能默认所有字段都参与比较。比如订单类 Order，可能有 id、status、amount、createdAt、updatedAt、version 等字段：
- id 是唯一标识，通常必须参与判等；
- status 变更（如“待支付”→“已支付”）不应影响两个订单是否代表同一笔业务，但若业务规则要求“仅未支付状态才可视为相同订单”，那就需纳入；
- updatedAt、version 属于操作痕迹或并发控制字段，一般不参与 equals；
- amount 若允许四舍五入或精度对齐（如支付系统中 9.999 元 ≈ 10.00 元），就不能用 == 或 Objects.equals，而要用自定义容差比较。
避免副作用与状态污染
equals 方法必须是纯函数：不修改对象状态、不抛出受检异常、不依赖外部可变状态（如当前时间、缓存、数据库）。常见陷阱包括：
- 在 equals 中调用 lazy-load 方法触发 Hibernate 初始化，导致 N+1 查询或 LazyInitializationException；
- 调用 getter 时内部做了格式化或远程调用（如 getDisplayName() 调用了用户服务）；
- 使用 SimpleDateFormat 格式化日期再比较——线程不安全且性能差。
正确做法：只比原始字段值，或提前缓存好用于判等的不可变视图（如把 formattedName 存为 final 字段）。
处理嵌套对象与集合的深度比较
当对象包含 List
、Map- 用 Objects.equals(list1, list2) 可行，但前提是 Address 本身也正确定义了 equals；
- 若集合顺序无关（如“收货地址集合相同即可”），应转为 Set 并确保元素可比较，或先排序再比；
- 对 Map，注意 key 的 equals/hashCode 是否可靠（例如用自定义对象作 key 时，其 equals 必须稳定）；
- 避免递归过深或循环引用——可在 equals 中加深度限制或使用 ThreadLocal 记录已访问对象。
保持 hashCode 与 equals 严格同步
只要 equals 返回 true，hashCode 就必须相同。复杂场景下容易遗漏：
- 若判等逻辑依赖某个计算字段（如 fullName = firstName + " " + lastName），hashCode 必须也基于 same logic，而不是只 hash firstName 和 lastName；
- 若使用 Lombok @EqualsAndHashCode，务必显式指定 field 或 exclude，否则可能意外包含不该比的字段（如 transient 或 volatile 字段）；
- 涉及浮点数时，hashCode 应用 Double.hashCode(d) 而非 (int)d，避免精度截断导致哈希不一致。
用单元测试守住契约底线
复杂业务的 equals 很难靠肉眼验证。建议每个重写都配套以下测试：
- 自反性：assertThat(obj).isEqualTo(obj)；
- 对称性：assertThat(a).isEqualTo(b); assertThat(b).isEqualTo(a)；
- 传递性：a==b && b==c ⇒ a==c；
- null 安全：assertThat(obj.equals(null)).isFalse()；
- 集合行为验证：new HashSet(Arrays.asList(a,b,c)) 的 size 是否符合预期。
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
