对称性与传递性是equals方法的核心契约，破坏会导致hashmap找不到key、hashset重复添加、treeset排序错乱；对称性破坏常见于继承中instanceof误用，应改用getclass()或使用record/final类；传递性失效多因子类扩展字段，需统一判等逻辑或改用组合/record；验证须构造三元组测试真值链及顺序交换。
因为对称性和传递性直接决定集合类能否正常工作——不满足，HashMap 可能找不到 key、HashSet 会重复添加相同逻辑对象、TreeSet 排序或去重结果错乱，这些不是理论风险，而是上线后立刻暴露的运行时问题。
对称性破坏：你认它，它不认你
最常见于继承场景下用 instanceof 判断类型：
- 父类
Person的equals允许和Student比较（obj instanceof Person对子类实例返回true） - 但子类
Student的equals只接受Student（obj instanceof Student对父类实例返回false） - 结果：
p.equals(s) == true，但s.equals(p) == false
后果：把 Student 实例作为 key 放进 HashMap 后，用 Person 实例去 get，一定返回 null；Set 也可能把两个逻辑相等的对象都加进去。
解法：用 getClass() == obj.getClass() 替代 instanceof，强制类型完全一致；更稳妥的是避免在可继承类中重写 equals，改用 record 或 final 类。
传递性失效：A=B、B=C，但 A≠C
典型诱因是子类“悄悄加字段”扩展判等逻辑：
- 父类
Person仅按name判等 - 子类
Student加了id字段，并在equals中同时比较name和id - 于是出现：
p1(name="A").equals(s1(name="A", id=1)) → true，s1.equals(s2(name="A", id=2)) → false，但p1.equals(s2) → true
这个链条断裂，会让 TreeSet 认为 s1 和 s2 不可比，排序异常；HashMap 在扩容再哈希时，可能把本该同桶的对象分到不同桶，导致 containsKey 返回错误结果。
解法：要么所有相关类统一用相同字段判等（比如都含 id），要么放弃继承式扩展，改用组合或 record —— 它的 equals 天然基于全部字段且不可被子类篡改。
验证不能只靠“两两相等”
光测 a.equals(b) 和 b.equals(a) 不够。必须构造三元组手动推演：
- 准备
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)完全相同
这种测试不是为了应付面试，而是提前发现那些“看起来没问题、一跑集合就崩”的隐性缺陷。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
