对称性与传递性是防止HashMap查不到key、Set重复添加、TreeSet排序错乱等实际问题的必要保障；对称性需用getClass()替代instanceof避免单向认可，传递性要求判等字段统一且继承时谨慎扩展，须用三元组手动验证。
确保对称性与传递性不是为了满足教条，而是防止 HashMap 查不到 key、Set 重复添加、TreeSet 排序错乱等真实问题。关键不在“写得像”，而在逻辑上不留下矛盾缺口。
对称性：避免 instanceof 引发的单向认可
对称性破坏最常见于继承场景：父类用 instanceof Parent 接受子类对象，但子类用 instanceof Child 拒绝父类对象，导致 p.equals(c) == true 而 c.equals(p) == false。
- 用
getClass() == obj.getClass()替代instanceof，强制类型完全一致 - 若确实需要跨类型比较（如 DTO 与实体），必须父子类双方约定并协同实现，不能只在一方加逻辑
- 更稳妥的做法是放弃在可继承类中重写 equals，改用 final 类、record 或组合封装
传递性：警惕字段扩展引入的逻辑断层
传递性失效往往藏在“渐进式增强”里：父类按 name 判等，子类加了 id 后只在自身实例间比较，结果出现 p1.equals(s1) → true、s1.equals(s2) → false、p1.equals(s2) → true 的矛盾链。
- 一旦类设计允许继承，就不要在子类中扩展 equals 的判等字段——要么全用父类字段，要么彻底放弃继承
- 若业务必须区分同类不同实例（如带 ID 的领域对象），就把 ID 纳入所有相关类的 equals 判据，保持判等维度统一
- 使用 record 替代普通类，其自动生成的 equals 天然基于全部字段且不可被子类篡改
验证是否真正满足：用三元组手动推演
别只测 a.equals(b)，要构造至少一组三对象组合，覆盖可能的类型和字段组合：
立即学习“Java免费学习笔记（深入）”；
- 准备
p1（Person, name="A"）、s1（Student, name="A", id=1）、s2（Student, name="A", id=2） - 检查
p1.equals(s1)、s1.equals(s2)、p1.equals(s2)是否形成一致真值链 - 交换参数顺序再跑一遍，确认
s1.equals(p1)结果与p1.equals(s1)完全相同
不复杂但容易忽略：对称性和传递性不是独立校验项，它们共同构成对象等价关系的数学基础。少一个，集合行为就可能偏离预期。
