重写 hashCode 的核心原则是：equals 相等的对象 hashCode 必须相同；需用 equals 中所有比较字段参与计算，推荐 Objects.hash(...)，避免可变字段，确保与 equals 逻辑一致且同步更新。
重写 hashCode 方法的核心原则是：只要两个对象通过 equals 判定为相等，它们的 hashCode 就必须相同；但 hashCode 相同，不意味着 equals 一定为 true。关键在于用 equals 中参与比较的**所有字段**来计算哈希值，并保持逻辑一致。
用 equals 涉及的字段参与 hashCode 计算
如果 equals 方法比较了 name、age 和 id 三个字段，那么 hashCode 也必须基于这三个字段生成结果。漏掉任何一个字段，就可能让逻辑相等的对象产生不同哈希值，破坏哈希表（如 HashMap、HashSet）的正确性。
- 推荐使用
Objects.hash(...)，它内部会自动处理null，并按指定字段顺序计算哈希值 - 避免手写复杂的质数乘法（如
31 * a + b），除非有特殊性能要求或学习目的 - 不要在
hashCode中使用可变字段（如普通 setter 修改的属性），否则对象放入哈希集合后修改字段会导致无法再被查到
确保 equals 和 hashCode 的一致性边界
两者必须“同进退”——当业务上认为两个对象相等时，不仅 equals 要返回 true，它们的 hashCode 值也必须相等。常见陷阱包括：
-
equals中用了Objects.equals(a, b)比较字符串，但hashCode却直接调用a.hashCode()（可能为null报NullPointerException） - 子类重写了
equals，却没同步更新hashCode，导致父类和子类实例在哈希结构中行为异常 - 使用 Lombok 的
@EqualsAndHashCode时，未显式指定include或exclude字段，导致生成的逻辑与手动写的equals不匹配
验证是否真正一致的简单方法
写一个单元测试，构造多个逻辑相等的对象，检查它们的 hashCode 是否全相同；再构造几个不相等的对象，观察哈希值是否尽量分散（不强求不同，但重复率过高会影响性能）。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 例如：
new Person("Alice", 25).equals(new Person("Alice", 25)) == true→ 二者hashCode()必须相等 - 用 IDE 自动生成（如 IntelliJ 的
Generate → equals() and hashCode()）能大幅降低出错概率，前提是选中的字段与equals实际逻辑完全一致 - 若字段含集合、数组或自定义对象，需确保其自身也正确实现了
hashCode（比如用Arrays.hashCode()处理数组，用list.hashCode()处理List）
不推荐但需了解的手动写法示例
虽然不建议手写，但理解原理有助于排查问题：
@Override
public int hashCode() {
int result = 1;
result = 31 * result + Objects.hashCode(name); // 注意用 Objects.hashCode 防 null
result = 31 * result + age;
result = 31 * result + Objects.hashCode(id);
return result;
}
其中 31 是常用质数，能较好减少哈希冲突；重点是每个参与 equals 比较的字段，都要以相同方式参与运算。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
