重写 equals 和 hashcode 的关键在于字段选择、计算方式与空值处理；优先用 objects.hash()，选影响逻辑相等且具区分度的字段，避集中值与冗余，浮点转位、数组用 arrays.hashcode，null 须安全处理，并通过抽样统计和单元测试验证分布与契约一致性。
重写 equals 和 hashCode 时，哈希分布质量不靠“玄学”，而取决于字段选择、计算方式和空值处理三个实操环节。只要避开常见陷阱，多数场景下用 Objects.hash() 就足够好。
选对参与计算的字段
不是所有字段都该放进哈希计算——关键看它是否影响逻辑相等性，且是否具备区分度：
- 只保留真正决定“对象是否相等”的字段（比如
Product类中必须是id和name，而不是createTime或status） - 剔除取值高度集中或几乎不变的字段（如全为
"ACTIVE"的status字段会让 99% 的对象哈希值趋同） - 避免冗余字段组合（例如同时用
year和date，而date已含年份信息）
用标准方式混合字段值
手动拼接容易出错，推荐优先使用 Java 自带的稳健方案：
- 直接调用
Objects.hash(field1, field2, field3)—— 它内部用素数 31 做乘加、自动处理 null、对字符串/数字等类型调用各自优化过的hashCode() - 若需手写，乘子用 31（
result = 31 * result + field.hashCode()），比用 30 或 100 更能打散数值分布 - 浮点字段必须先转位表示：
Float.floatToIntBits(f)或Double.doubleToLongBits(d)，否则NaN和-0.0会破坏一致性 - 数组字段不能直接用
array.hashCode()（那是引用哈希），改用Arrays.hashCode(array)
警惕 null 和边界情况
null 不是异常，而是常见状态；处理不当会直接拉低区分度：
-
Objects.hash()对 null 返回 0，安全但可能削弱差异性；若字段常为空，可考虑用哨兵值替代（如name == null ? "NULL_NAME" : name） - 自定义逻辑中显式判 null，避免
field.hashCode()报 NPE，也避免多个 null 字段叠加导致哈希值全为 0 - 注意包装类型与基本类型的混用：
Integer的hashCode()返回其 int 值，但int字段要转成Integer.hashCode(value)才统一
验证是否真的改善了分布
别只靠“看起来合理”，简单验证能暴露真实问题：
- 抽样一批真实业务对象（比如 1 万条订单），统计它们的
hashCode()模 16 或模 64 的余数分布，看是否明显偏斜 - 在
HashMap中插入大量对象后，调用map.size()和map.entrySet().stream().map(e -> e.getKey().hashCode() % map.capacity()).distinct().count()粗略观察桶利用率 - 单元测试里加断言：
assertTrue(a.equals(b) == (a.hashCode() == b.hashCode()))，确保契约没被意外打破
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
