关键在于用奇素数乘法累积（如31 * result + fieldhash）使各字段贡献独立可叠加，避免直接相加导致权重失衡，31的二进制特性还利于jvm优化。
关键在于让每个字段对最终哈希值的贡献既独立又可叠加，避免某些字段“淹没”其他字段，也不让低信息量字段拖累整体离散性。
用奇素数乘法累积，防止字段权重失衡
直接相加（如 a.hashCode() + b.hashCode()）会让数值型字段和字符串字段影响力严重不对等——一个大整数可能抵消几十个字符的哈希变化。改用 31 * result + fieldHash 这类累积方式，能给靠后字段赋予更高权重，同时利用 31 的二进制特性（i * 31 被 JVM 优化为 i ），兼顾效率与分布。
- 字段顺序影响权重：先参与计算的字段受乘数放大次数少，后参与的被多次放大；业务上更稳定的字段（如 ID）建议放前面，易变字段（如状态码）放后面
- 避免使用偶数或 2 的幂作乘数，否则会丢失低位信息；31 是经过验证的平衡选择
- 若字段本身是复合对象（如嵌套 record），直接调用其
hashCode()即可，无需手动拆解
差异化处理字段类型，不一刀切
不同字段天然携带的信息熵不同，统一调用 hashCode() 可能放大偏差。应按类型分层处理：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
字符串：直接用
String.hashCode()—— 它内部已做高效混合，再套一层 Objects.hash 反而冗余；但长文本（如 JSON、HTML 片段）建议截取前 64 字符或用 CRC32 摘要，防止单字段主导整个哈希值 -
数值型：
int/long直接参与运算；double/float先转Double.doubleToLongBits()再取 hashCode，避免 NaN 和 ±0 的歧义 -
布尔与枚举：布尔转
field ? 1 : 0，枚举优先用ordinal()（稳定且轻量），若需跨版本兼容则定义固定码表 -
集合类：
List/Set用Objects.hashCode(collection)，它内部遍历并累积；但若集合很大或含重复元素，考虑只哈希其size()和首尾元素
剔除无关字段，聚焦区分性维度
参与哈希计算的字段必须满足两个条件：在 equals() 中被比较，且能有效区分不同实例。无关字段不仅不提升均匀性，反而引入噪声：
- 跳过时间戳（
createTime）、版本号（version）、备注（remark）等非标识字段 - 若业务主键是
tenantId + bizCode + id组合，就只用这三项；不要把status或updateTime加进去 - 对 null 值统一映射为 0（如
field == null ? 0 : field.hashCode()），避免 null 导致哈希值塌缩
缓存结果并保证不可变性
一旦字段影响力分配确定，就要固化计算结果——反复调用 hashCode() 时，各字段的相对权重必须严格一致：
- 声明
private final int hashCode，构造时一次性算出并赋值 -
hashCode()方法体仅一行：return hashCode;，杜绝运行时重新计算 - 前提是 Key 类必须不可变（所有字段 final，无 setter，无对外暴露可变容器）；否则缓存失效，一致性崩溃
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
