equals和hashCode必须一起重写以保障哈希集合正确性与性能；equals定义逻辑相等，hashCode决定哈希桶定位，二者契约违反将导致查找失败、去重失效或性能下降。
Java中equals和hashCode之所以重要，根本原因在于：它们共同支撑了哈希集合（如HashMap、HashSet）的正确性与性能。一旦二者契约被破坏，看似正常的代码可能在运行时悄然失效——比如键查不到、重复元素无法去重、缓存命中率归零。
equals决定“逻辑上是否同一个东西”
默认的equals只比内存地址，也就是==行为。两个new User("张三", 25)对象，哪怕字段一模一样，也会被判为不相等。
业务中真正需要的是内容比较。例如：
- 用户登录时，用手机号+密码封装成
LoginRequest作为HashMap的key，必须靠重写的equals识别出“相同请求”； -
HashSet去重订单，得依据订单号判断是否重复，而不是看是不是同一个对象实例。
重写equals必须遵守五项规范：自反、对称、传递、一致、非空。违反任一条，集合操作就可能出错——比如HashSet.contains(x)返回false，即使x明明在里面。
立即学习“Java免费学习笔记（深入）”；
hashCode决定“先去哪个抽屉找”
hashCode不是为了唯一标识对象，而是快速定位。它把对象映射到哈希表的一个“桶”（bucket）里，后续才用equals在桶内逐个比对。
关键点：
- 同一对象多次调用
hashCode()，只要参与equals的字段没变，结果必须相同； - 如果
a.equals(b) == true，那么a.hashCode() == b.hashCode()是强制要求； - 但
hashCode相同，equals不一定为true——这叫哈希冲突，是正常现象，由链表或红黑树处理。
不重写hashCode却重写了equals，等于告诉HashMap：“去1号抽屉找”，但它实际把对象放进了3号抽屉——永远找不到。
二者必须一起重写，不能只改一个
这是Java规范明确规定的契约，不是建议，是硬性约束。常见错误场景：
- 只重写
equals：两个逻辑相等的对象因hashCode不同，被散列到不同桶中，HashMap.get()返回null，HashSet.add()插入重复项； - 只重写
hashCode：两个内容不同的对象哈希值碰巧一样，桶内equals始终返回false，导致集合误判为不重复，但性能下降（桶变长）； - 重写后未同步更新：比如
User类新增了email字段参与相等判断，但hashCode仍只基于name和age计算，就会打破契约。
IDE（如IntelliJ）生成的重写代码通常已兼顾二者，但务必检查字段是否完整覆盖，尤其注意null安全（用Objects.equals(a, b)和Objects.hash(...)可大幅降低出错概率）。
典型重写示例（安全、简洁、可维护）
以Product类为例，用productId和name定义相等性：
// 不用手算，用标准工具类
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Product product = (Product) o;
return Objects.equals(productId, product.productId)
&& Objects.equals(name, product.name);
}
@Override
public int hashCode() {
return Objects.hash(productId, name);
}
这种写法天然满足一致性、空安全，且与equals所用字段严格对应，不易遗漏或错位。
