不重写 hashCode 会导致 HashMap 出问题，因为 equals 相等的对象若 hashCode 不同，会被散列到不同桶中，使 get/contains 失效，违反 Object 合约；修复需确保参与 equals 比较的字段全部用于计算 hashCode。
为什么重写 equals 不重写 hashCode 会导致 HashMap 出问题
Java 中 HashMap、HashSet 等集合依赖 hashCode 定位桶位置，再用 equals 判定是否为同一键。如果只重写 equals，两个逻辑上相等的对象可能返回不同 hashCode，结果被散列到不同桶里——map.get(obj) 找不到，set.contains(obj) 返回 false，即使它们 equals 为 true。
这是违反 Object 合约的硬性约束：若 a.equals(b) 为 true，则 a.hashCode() 必须等于 b.hashCode()。
- 常见错误现象：
HashMap.put(new Person("Alice", 30), "A")后，map.get(new Person("Alice", 30))返回null - 根本原因：两个
Person实例字段相同、equals返回true，但默认hashCode是内存地址，不一致 - 修复原则：参与
equals比较的字段，必须全部用于计算hashCode
手写 equals 的关键检查点（含 null 和类型安全）
手写 equals 不是简单比较字段，要覆盖边界情况，否则会抛 NullPointerException 或在集合中行为异常。
- 先用
==判断是否为同一引用（提升性能，且能正确处理null自比较） - 用
instanceof检查参数类型，避免ClassCastException；若子类重写，建议用getClass() == obj.getClass()防止不对称比较 - 强转后，对每个用于判等的字段分别处理：
Objects.equals(field1, other.field1)（自动处理null） - 不要用
==比较字符串或包装类字段，也不要漏掉double/float的Double.compare等专用方法
public boolean equals(Object obj) {
if (this == obj) return true;
if (obj == null || getClass() != obj.getClass())
return false;
Person person = (Person) obj;
return age == person.age &&
Objects.equals(name, person.name);
}
用 Objects.hash 写 hashCode 最省心也最安全
手动组合哈希值容易出错：比如 31 * name.hashCode() + age 要注意乘法溢出、顺序敏感、空指针。JDK 7+ 提供的 Objects.hash(...) 内部已处理所有边界，推荐直接使用。
- 参数列表必须和
equals中参与比较的字段完全一致（顺序也要一致） - 它会自动对
null返回 0，对数组调用Arrays.hashCode，无需额外判断 - 不要用随机数、时间戳、数据库 ID 等可变值参与计算——
hashCode必须在对象生命周期内稳定
public int hashCode() {
return Objects.hash(name, age);
}IDE 自动生成 vs 手写：什么情况下不能偷懒
IntelliJ / Eclipse 的 “Generate equals and hashCode” 功能基本可靠，但有三个典型场景必须人工干预：
- 实体类含
java.util.Date字段：默认生成会用date.getTime()，但若业务允许“秒级相等”，需改成date.toInstant().truncatedTo(ChronoUnit.SECONDS)再哈希 - 含集合字段（如
List）：自动生成调用list.hashCode()，但若业务要求忽略顺序，就得先排序再哈希 - 继承自非 final 类且子类可能扩展字段：自动生成通常只处理本类字段，若子类也重写
equals，需确认是否满足 Liskov 替换原则，必要时改用getClass()判等
真正容易被忽略的不是怎么写，而是“改了业务字段后有没有同步更新 equals 和 hashCode”——只要加了一个参与语义判等的新字段，两方法就必须同时修订，缺一不可。
