重写 hashCode 无法完全避免冲突，关键在于保证 equals 相等的对象 hashCode 必须相同，且尽量分散不等对象的哈希值；必须用所有参与 equals 比较的字段计算，推荐 Objects.hash() 或 IDE 自动生成，并确保字段不可变以防止哈希值漂移。
重写 hashCode 方法本身无法完全避免冲突，因为哈希值是 int 类型（仅 2³² 种可能），而业务对象状态空间远大于此。Java 的目标不是“不冲突”，而是“合理分散 + 正确处理冲突”。关键在于：让逻辑相等的对象哈希值一定相同，同时让不相等的对象尽量产生不同哈希值，从而减少链表长度、维持 HashMap/HashSet 的平均 O(1) 性能。
用参与 equals 比较的全部字段计算哈希值
冲突常源于字段遗漏或逻辑错位。只要 equals 里比较了 name、age、id，hashCode 就必须全量使用这三个字段——漏一个，就可能让本该相等的对象散列到不同桶中，导致查找失败。
- 推荐直接使用
Objects.hash(name, age, id)：它自动处理null，按顺序组合字段，内部采用成熟扰动算法，冲突率低且无需手算质数 - 避免只用部分字段（如只用
id）：虽然看似“唯一”，但若equals还依赖name，就会破坏契约 - 不要用未参与
equals的字段（如createTime）：这会让逻辑相等的对象哈希值不同，直接违反规范
优先选用不可变字段，避免运行时哈希值漂移
如果对象加入 HashSet 或作为 HashMap 的 key 后，你又修改了用于计算 hashCode 的字段（比如调用 setName("Bob")），它的哈希值就变了，但集合内部仍把它放在旧桶里——从此再也查不到，也不再被识别为重复，造成“幽灵元素”。
- 设计上尽量让参与
hashCode的字段在构造后不可变（final） - 若必须可变，应在修改前从集合中
remove，修改后再add - 避免在
hashCode中调用可能改变状态的 getter（如带懒加载逻辑的方法）
借助工具生成，而非手动拼接
手写 31 * Objects.hashCode(name) + age 看似可控，实则易错：容易忽略 null 安全、顺序颠倒、括号缺失，甚至误用浮点字段的 Float.floatToIntBits() 等细节。
立即学习“Java免费学习笔记（深入）”；
- IDE（如 IntelliJ）的
Generate → equals() and hashCode()是首选：选中的字段与equals实现严格对齐，零配置误差 - Lombok 的
@EqualsAndHashCode可用，但务必显式指定include或of字段，防止注解默认行为与业务逻辑脱节 - 数组、集合类字段需特殊处理：用
Arrays.hashCode(arr)、list.hashCode()，它们自身已实现良好散列
验证冲突是否“合理”而非“有无”
两个不同对象哈希值相同不一定是 bug，这是哈希表的正常现象（JDK 就靠链表/红黑树解决）。真正要检查的是：
- 所有
equals返回true的对象，hashCode是否完全一致？——这是硬性要求，必须通过单元测试覆盖 - 大量不相等对象的哈希值是否明显聚集（如 90% 落在前 5 个桶）？可用简单统计辅助观察，必要时调整字段权重或补充关键区分字段
- 注意 JVM 默认哈希算法（基于地址）与重写后的差异：重写后冲突模式会变，但只要满足契约，性能通常更好
