object类中equals默认仅作引用比较，重写时须用getclass()校验类型以保障对称性与传递性，避免instanceof导致的父子类比较问题；同时必须同步更新hashcode，确保相等对象具有相同哈希值。
在 Object 类中，equals 默认只做引用比较（this == obj），天然满足对称性、传递性等契约。但一旦你重写它，就必须主动保障这些原则——不是靠默认行为，而是靠逻辑设计。
对称性必须靠类型校验来守住
常见错误是用 instanceof 做类型检查，导致子类与父类比较时单向成立、反向失败。比如 A extends B，若 B.equals(A) 返回 true，但 A.equals(B) 因类型不匹配返回 false，就破坏了对称性。
- 推荐统一使用
getClass() == obj.getClass()判断类型，确保比较双方是同一运行时类 - 仅当类被声明为
final，且明确放弃继承扩展时，才可谨慎使用instanceof - 避免跨类型“友好兼容”，例如让
String和自定义字符串类互相 equals，极易打破对称
传递性依赖字段一致性与继承设计
传递性失效多发生在继承链中：父类 Person 比较 name/age，子类 Employee 多加了 id 字段。此时可能出现 p.equals(e1) && e1.equals(e2) 为 true，但 p.equals(e2) 却为 false。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 最稳妥的做法是禁止用
instanceof跨类比较，坚持getClass()校验，让父子类对象天然不相等 - 若业务真需多态相等（如所有用户 ID 都只比 value），应把相等逻辑上提到接口或抽象基类，并确保所有实现严格按同一字段集判断
- 更推荐用组合替代继承：把可复用的字段封装成独立组件，再由各业务类持有并参与 equals，避免类型层级干扰
每一步都得检查 null 和引用自身
对称性和传递性看似高阶，其实根基在开头两行代码里：
- 先写
if (this == obj) return true;—— 保证自反性，也避免后续空指针 - 再写
if (obj == null || getClass() != obj.getClass()) return false;—— 同时拦截 null 和类型不匹配，是对称与传递的前提 - 之后才安全转型、逐字段比较；建议用
Objects.equals(a, b)处理可能为 null 的字段，避免手动判空出错
hashCode 必须同步更新
虽然不直接决定对称或传递，但若两个对象 equals 返回 true，而 hashCode 不同，它们在 HashMap 或 HashSet 中会被散列到不同桶里，导致逻辑上“相等却查不到”，间接破坏集合行为的一致性——这会让对称、传递等原则在实际运行中失效。
- 务必重写
hashCode，且逻辑与equals中参与比较的字段完全一致 - 推荐用
Objects.hash(field1, field2, ...)生成，既简洁又保证空安全 - 任何修改
equals字段的行为，都必须同步审视hashCode是否仍匹配
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
