根本原因是只重写equals()未重写hashCode()，导致逻辑相等的对象被散列到不同桶中，equals()无法触发；Java规范要求二者必须同时重写。
为什么 equals() 返回 true，但放进 HashSet 还是重复？
根本原因：只重写 equals()，没重写 hashCode()。Java 集合（如 HashSet、HashMap）依赖 hashCode() 快速定位桶位置，再用 equals() 做精确比对。如果两个逻辑相等的对象 hashCode() 不同，它们大概率被散列到不同桶里，equals() 根本不会被调用。
实操建议：
- 只要重写
equals()，就必须同步重写hashCode()—— 这是 Java 规范的硬性要求，不是可选项 - IDE（如 IntelliJ）可自动生成两者，但需确认生成逻辑是否覆盖所有参与比较的字段（比如漏了
id或用了float字段直接参与哈希计算） - 避免在
hashCode()中使用可变字段（如普通 setter 可修改的属性），否则对象加入HashSet后再改字段，会导致无法被remove()或contains()到
equals() 里用 == 还是 .equals() 比较字符串字段？
必须用 .equals()。字段是引用类型时，== 比的是内存地址，而业务上我们关心的是值是否相同。尤其字符串常量池机制会让部分字面量字符串共享地址，但不能依赖这个行为做逻辑判断。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
- 自定义类中字符串字段用
==判断，导致两个内容相同的对象equals()返回false - 字段为
null时调用.equals()报NullPointerException—— 正确写法是"abc".equals(str)或先判空 - 忽略大小写需求：该用
String.equalsIgnoreCase()时用了.equals()
重写 hashCode() 时，为什么推荐用 Objects.hash()？
它内部做了空安全处理，并基于传入字段的 hashCode() 值组合出一个合理整数，比手写乘加运算（如 31 * a + b）更简洁、不易出错。手动实现容易漏字段、顺序写反、或对 null 处理不当。
示例对比：
// 推荐：简洁且安全
@Override
public int hashCode() {
return Objects.hash(id, name, email);
}
// 不推荐：易漏字段，且 name 为 null 时抛 NPE
@Override
public int hashCode() {
return 31 * id + name.hashCode() + email.hashCode();
}
注意：Objects.hash() 性能略低于极致手写，但对绝大多数业务场景无感知；若字段含数组，需用 Arrays.hashCode() 单独处理，Objects.hash() 对数组只返回其引用哈希值。
集合操作中，contains() 和 remove() 为什么有时不生效？
本质是对象在集合中“找不到了”——通常因为 hashCode() 或 equals() 行为在对象存入后发生了变化，或实现本身不满足对称性、传递性等契约。
排查要点：
- 检查是否在对象加入
HashSet/HashMap后修改了参与hashCode()计算的字段 - 确认
equals()实现满足：自反性（x.equals(x)为true）、对称性（x.equals(y) == y.equals(x)）、传递性、一致性 - 留意 IDE 自动生成的
equals()是否包含父类字段（若继承自非Object类，可能需要显式调用super.equals()） - 若用 Lombok，确保
@EqualsAndHashCode注解的include/exclude配置正确，且未意外排除关键字段
最隐蔽的问题往往不在代码逻辑本身，而在对象生命周期与集合容器的交互时机 —— 放进去之后就不能动哈希依据，这点比语法细节更值得反复确认。
