重写equals时必须保证对称性和传递性，否则hashmap、hashset、treeset等集合类行为异常；用getclass()替代instanceof确保对称，判等字段须不可变且统一，需手动验证三元组一致性。
重写 equals 时，对称性和传递性不是附加要求，而是集合类正常工作的前提。HashMap 查不到 key、HashSet 重复添加、TreeSet 排序异常，往往就卡在这两点上。
用 getClass() 替代 instanceof 保对称
对称性破环最常见于父子类互判不等：父类用 instanceof Parent 接受子类对象，子类却因加了字段校验而拒绝父类，结果 p.equals(s) == true，但 s.equals(p) == false。
- 统一用
if (getClass() != obj.getClass()) return false;，强制只同类型比较 - 避免单方面扩展逻辑——如果真需要跨类型相等（如 DTO 和实体），必须双方约定、双向实现，不能只在一方加分支
- 更稳妥的做法是把类声明为
final，或直接用record，天然规避继承带来的对称风险
判等字段必须稳定且统一保传递
传递性失效常藏在“字段不一致”里：父类按 name 判等，子类加了 id 后只在自身实例间比，就可能出现 p1.equals(s1) → true、s1.equals(s2) → false、p1.equals(s2) → true 的矛盾链。
- 所有参与
equals的字段，必须不可变、语义唯一、业务上构成身份标识（如数据库主键id） - 禁止在子类中擅自增加判等字段；若必须区分，就把
id纳入所有相关类的判据，保持维度一致 - 避免混用可变字段（如
lastModified）或易空字段，它们会让相等关系随状态漂移，间接切断传递链
手动验证三元组，别只测两两相等
光测 a.equals(b) 和 b.equals(c) 不够，得构造具体对象组合，覆盖类型与字段组合变化。
- 准备
p1 = new Person("Alice")、s1 = new Student("Alice", 101)、s2 = new Student("Alice", 102) - 检查
p1.equals(s1)、s1.equals(s2)、p1.equals(s2)是否形成一致真值链 - 再交换顺序跑一遍：
s1.equals(p1)必须和p1.equals(s1)完全相同
不复杂但容易忽略：对称性和传递性是相互支撑的。少一个，对象等价关系就不成立，集合行为就会偏离预期。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
