传递性要求若a等于b且b等于c，则a必须等于c，关键在于只比较不可变、语义一致的唯一标识字段（如主键id），禁用可变字段和instanceof，统一用getclass()与objects.equals确保空安全和类型严格匹配。
重写 equals 方法时，保证逻辑的正确传递性，关键在于确保“若 A 等于 B，且 B 等于 C，则 A 必须等于 C”这一关系始终成立。传递性不是自动满足的，稍有不慎就会因字段选择、类型处理或继承设计而被破坏。
只比较不可变且语义一致的关键字段
传递性失效常源于参与比较的字段本身不具备传递基础。例如混用 ID 和业务字段、引入可变状态、或在子类中擅自扩展判断条件。
- 优先使用唯一标识字段（如数据库主键
id）作为核心判等依据，它天然满足传递性 - 避免将可变字段（如
lastLoginTime、status）纳入equals比较——对象状态变化后，相等关系可能突变，破坏一致性，间接影响传递链 - 若需多字段联合判断（如姓名 + 出生日期），确保这些字段组合在业务上构成稳定、无歧义的身份标识
严格使用 getClass() 而非 instanceof
在继承体系中，用 instanceof 容易导致对称性和传递性同时崩溃。例如父类 Person 与子类 Employee 若都用 instanceof Person 判断，可能出现：person.equals(employee) == true，但 employee.equals(person) == false（因子类重写逻辑更严），进而使传递链断裂。
- 统一用
getClass() == obj.getClass()做类型检查，确保比较只发生在同类型实例之间 - 如果确实需要跨父子类相等（极少数场景），应由顶层父类统一定义契约，并禁止子类覆盖
equals，改用组合而非继承
字段比较必须空安全且语义对等
一个字段为 null、另一个为非空字符串，或两个 BigDecimal 因精度不同判定不等，都可能切断传递路径。比如 A.name = null，B.name = "Tom"，C.name = null；若 A.equals(B) 为 false、B.equals(C) 为 false，但 A.equals(C) 却为 true —— 表面没问题，可一旦加入其他字段（如 age），就容易因空处理不一致引发矛盾。
- 一律使用
Objects.equals(a, b)替代a.equals(b)，它能安全处理null - 对数值型包装类（
Integer、BigDecimal）、集合、数组等，确认其equals实现符合你的业务语义（例如BigDecimal.equals()包含精度，而compareTo()不包含） - 避免在比较中调用可能抛异常或依赖外部状态的方法（如自定义 getter 中含远程调用）
避免在 equals 中引入外部依赖或运行时状态
如果 equals 内部访问缓存、数据库、当前时间或随机数，结果将随调用时机变化，多次比较返回不同值，直接违反一致性，继而让传递性失去前提。
- 所有比较逻辑必须是纯函数式的：输入相同对象 → 输出恒定布尔值
- 不读取静态变量、不调用非 final 方法、不依赖线程局部变量或系统时间
- 单元测试中可构造固定数据集，验证 A=B、B=C ⇒ A=C 的三元组是否始终成立
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
