hashCode未重写会导致HashMap/HashSet功能失效：对象被分到不同桶中，即使equals为true也无法查找或去重；必须与equals使用相同字段计算，且字段不可变。
hashCode决定HashMap/HashSet能不能找到你的对象
它不是“重要”，而是“失效即崩溃”——如果你把自定义对象当 HashMap 的 key 或放进 HashSet，但没重写 hashCode()，那几乎肯定查不到、去不掉、判不了重。
原因很简单：集合先用 hashCode() 算出该去哪个桶（bucket），再在那个桶里用 equals() 找具体对象。如果两个逻辑上相等的对象（equals() == true）返回不同哈希码，它们会被分到不同桶里，contains() 或 get() 就永远找不到对方。
- 错误现象：
set.contains(new User(1, "Alice"))返回false，哪怕这个User刚刚被add()进去 - 根源：只重写了
equals()，却沿用Object.hashCode()（基于内存地址） - 后果：不是“慢一点”，而是逻辑错误——集合行为完全不可信
重写hashCode必须和equals用同一套字段
不是“随便挑几个字段算个数”，而是严格对齐 equals() 的判断依据。漏一个、多一个、类型不一致，都会破坏契约。
比如你 equals() 里只比了 id 和 name，那 hashCode() 就只能用这两个字段参与计算；如果还塞进 createdAt（且该字段可变），就违反了“一致性”原则——对象内容没变，哈希码却可能变。
立即学习“Java免费学习笔记（深入）”；
- 安全做法：用
Objects.hash(id, name)，简洁且自动处理 null - 手动实现时，乘数选
31不是玄学——31 * i == (i ，JVM 能优化成位运算，快 - 绝对避免：在
hashCode()中调用可能改变状态的方法（如computeHash()），或读取非 final 字段（除非你确保它永不变更）
哈希冲突不是 bug，但分布不均就是性能杀手
两个不同对象 hashCode() 相同，完全合法（叫“哈希冲突”），HashMap 本就设计来处理它。真正要命的是大量对象挤进同一个桶——比如所有对象哈希码都是 0，整个哈希表退化成链表，O(1) 变 O(n)。
- 常见坑：只用一个字段（如全用
id % 10）或常量（return 42;）做哈希码，导致极端倾斜 - 检测手段：打印
map.size()和map.entrySet().stream().map(e -> e.getKey().hashCode()).distinct().count()，如果后者远小于前者，说明冲突严重 - 改善方向：字段组合要“有区分度”——字符串用
String.hashCode()（已优化），数字别直接返回原值，用异或或质数加权
String、Integer等包装类已经帮你写好了，别自己造轮子
别看到 "abc".hashCode() 是 96354，就以为能照搬公式；也别因为 Integer.valueOf(123).hashCode() == 123，就给自己的 Id 类直接 return this.value。
这些 JDK 类的 hashCode() 经过长期验证，兼顾分布性、计算速度和向后兼容。你自己手写的，哪怕看起来“差不多”，也可能在边界值（空字符串、负数、大 Long 转 int 截断）上翻车。
- 正确姿势：继承标准类（如
extends Integer）或组合（private final int id;），然后复用其hashCode() - 错误姿势：复制粘贴网上“通用 hashCode 模板”，却不验证字段是否参与
equals()、是否可变、是否为 null 安全 - 底线提醒：只要对象进了哈希集合，它的
hashCode()就不能随外部修改而变化——哪怕你后来改了对象的某个字段，只要它还在集合里，哈希码就得和当初加入时一模一样
