hashCode()与equals()必须同时重写，因为哈希集合依赖hashCode快速定位桶、equals精准判等；若equals为true而hashCode不同，会导致重复插入、查找失败等错误。
在Java中，hashCode() 和 equals() 必须配合使用，根本原因在于：哈希集合（如 HashMap、HashSet）依赖二者协同完成“快速定位 + 精准判等”两个关键步骤。只重写一个，会直接破坏集合行为的正确性。
哈希结构如何工作：先桶后比
哈希集合底层是数组+链表/红黑树的结构。插入或查找时：
- 先调用
key.hashCode()，取模后确定该对象应归属的“桶”（数组索引） - 再在该桶内遍历元素，逐个调用
equals()判断是否真正相等
这个流程决定了：如果两个逻辑上相等的对象（a.equals(b) == true）却返回不同哈希值，它们会被散列到不同桶中——get() 找不到，add() 重复插入，contains() 返回 false，Bug 就产生了。
为何 equals 相等 ⇒ hashCode 必须相等
这是 Java 规范强制要求的契约（JLS §3.10.2），不是建议而是硬约束。因为：
立即学习“Java免费学习笔记（深入）”；
-
hashCode()是equals()的“前置筛选器”：它不负责最终判定，但必须保证“相等者不可被筛漏” - 若违反，哈希集合将无法识别语义相同的对象，违背集合去重、键唯一等基本语义
- 比如
new User(1, "A")和new User(1, "B")若仅按id判equals，那它们的hashCode也必须只基于id计算
为何 hashCode 相等 ⇏ equals 不一定相等
这是由哈希函数的本质决定的：
-
int值只有约 42 亿种可能，而实际对象数量远超此限，哈希碰撞不可避免 - 设计良好的
hashCode()应尽量均匀分布，但无法完全避免冲突 - 所以桶内仍需
equals()进行最终确认——这正是二者分工：hashCode负责“快”，equals负责“准”
不配合的典型后果示例
假设自定义类只重写 equals()（按业务字段比较），但没重写 hashCode()：
- 两个内容相同的新对象，
equals()返回true，但hashCode()返回内存地址相关值 → 值不同 - 放入
HashSet后，它们被存入不同桶 → 集合大小变成 2，而非预期的 1 - 用其中一个作
map.get(key)，因哈希值不匹配，直接跳过对应桶 → 返回null
这种问题在线上环境往往表现为“数据丢失”或“重复提交”，隐蔽且难复现。
