equals()相等则hashCode()必须相等，这是Java规范强制契约；因HashSet/HashMap先用hashCode定位桶，再用equals判等，若不一致会导致重复添加、查找失败等逻辑错误。
是的，两个对象 equals() 相等，它们的 hashCode() 必须相等；但反过来不成立——hashCode() 相等，equals() 不一定相等。
为什么 equals() 相等 ⇒ hashCode() 必须相等
这是 Java 规范强制要求的契约，不是建议，而是必须遵守的规则。原因在于哈希集合（如 HashSet、HashMap）依赖这个一致性来正常工作：
- 当对象被放入
HashSet时，先用hashCode()定位到某个“桶”（bucket）； - 再在该桶内调用
equals()判断是否已存在相同元素； - 如果
equals()为true但hashCode()不同，对象会被散列到不同桶中 → 集合误判为“不重复”，导致逻辑错误（比如重复添加、contains()返回false）。
为什么 hashCode() 相等 ⇏ equals() 不一定相等
这叫“哈希冲突”，是正常且允许的：
javascript-typescript-typescript-scaffold
下载
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
-
hashCode()返回的是int（32 位），而对象状态空间远大于2³²，必然存在不同对象算出相同哈希值； - 哈希表的设计本就容忍冲突：只要冲突后能用
equals()正确区分即可； - 例如：
"ABC".hashCode()和"BCE".hashCode()可能相同，但字符串内容不同，equals()返回false。
重写 equals() 时必须同步重写 hashCode()
否则会直接破坏上述契约：
- 若只重写
equals()（比如按name和age比较），却不重写hashCode()，两个逻辑相等的对象仍使用默认（基于内存地址）的哈希值 → 几乎必然不同； - 推荐用
Objects.hash(field1, field2, ...)实现，确保参与equals()比较的字段也参与hashCode()计算； - 同一对象多次调用
hashCode()，只要用于比较的字段未变，结果必须一致。
不重写的典型后果
看似代码能编译运行，但集合行为会出人意料：
-
HashSet.add(p1)和set.contains(p2)（其中p1.equals(p2) == true）可能返回false； -
HashMap中用p1存的值，用p2去取不到； - 调试困难，问题常出现在生产环境，且难以复现。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
