equals定义逻辑相等，hashCode提供哈希表快速定位；若a.equals(b)为true，则a.hashCode()必须等于b.hashCode()，否则HashMap、HashSet等集合会出现去重失效或查找失败等静默故障。
要全面复习 equals 与 hashCode 的核心概念，关键不是背定义，而是理清“为什么这样设计”和“不遵守会怎样”。它们不是孤立方法，而是一套协同工作的契约体系，直接决定 HashMap、HashSet 等集合能否正常工作。
equals 是干什么的？不是“比较”，而是“定义相等”
默认的 equals() 比较的是引用（this == obj），也就是两个变量是否指向堆里同一个对象。这在业务中几乎没用——我们关心的是“内容相同”，比如两个 Person 对象 name 和 age 都一样，就该算相等。重写 equals()，本质是告诉 JVM：“在我的世界里，满足这些字段一致，就是逻辑相等”。但重写必须守规矩：
• 自反性：x.equals(x) 必须为 true
• 对称性：x.equals(y) 为 true → y.equals(x) 也得为 true（继承时容易破）
• 传递性：x=y 且 y=z → x=z
• 一致性：对象不变，结果就不能变
• 非空性：x.equals(null) 永远返回 false
hashCode 是干什么的？它是哈希表的“快速路标”
hashCode() 返回一个 int，不负责判断相等，只负责把对象“大致分组”。HashMap 插入或查找时，先调 hashCode() 算出桶号（index = (n - 1) & hash），再在那个桶里用 equals() 逐个比对。所以它像快递分拣：先按邮编（hashCode）分到区，再按门牌号（equals）送上门。它的核心要求只有两条：
• 一致性：对象状态未变，多次调用 hashCode() 必须返回相同值
• 相等必同码：如果 a.equals(b) 为 true，则 a.hashCode() == b.hashCode() 必须成立
为什么必须一起重写？单写 equals 就等于埋雷
只重写 equals() 不碰 hashCode()，是最常见也最危险的错误。例如：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
• 创建两个 Person("张三", 25)，重写了 equals() 认为它们相等
• 但没重写 hashCode()，走 Object 默认实现 → 生成两个不同哈希值
• 把它们放进 HashSet → 被分到两个不同桶里
• 调用 set.contains(另一个张三) → 先找桶，桶都不对，直接返回 false，哪怕它们逻辑上完全一样
这种问题不会编译报错，也不会运行崩溃，只会让集合行为诡异、数据丢失、去重失效——典型的“静默故障”。
怎么写才安全？推荐现代写法
别手算 31 * result + field.hashCode()，容易漏字段、写错顺序、忽略 null。直接用 JDK 提供的工具：
• equals()：先用 if (this == obj) return true; 检引用；再 if (obj == null || getClass() != obj.getClass()) return false; 排 null 和类型；最后用 Objects.equals(field1, other.field1) && Objects.equals(field2, other.field2)
• hashCode()：一行搞定 —— return Objects.hash(field1, field2, field3);
• 进阶：用 Lombok 的 @EqualsAndHashCode，但注意检查是否包含父类字段、是否排除了可变字段（如 status、lastModified）
