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。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 最稳妥的做法是禁止用
instanceof跨类比较，坚持getClass()校验，让父子类对象天然不相等 - 若业务真需多态相等（如所有用户 ID 都只比 value），应把相等逻辑上提到接口或抽象基类，并确保所有实现严格按同一字段集判断
- 更推荐用组合替代继承：把可复用的字段封装成独立组件，再由各业务类持有并参与 equals，避免类型层级干扰
每一步都得检查 null 和引用自身
对称性和传递性看似高阶，其实根基在开头两行代码里：
立即学习“Java免费学习笔记（深入）”；
- 先写
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是否仍匹配
