hashset.add()能去重，关键在于hashcode()与equals()协同工作：先用hashcode()定位桶，再用equals()精确比对；二者必须一致，否则导致假重复或性能退化。
HashSet.add() 为什么能去重？关键在 hashCode() 和 equals()
不是靠 add() 自己判断重复，而是它内部先用 hashCode() 快速定位桶位置，再用 equals() 精确比对。两个方法必须协同工作：如果两个对象逻辑相等（equals() 返回 true），它们的 hashCode() **必须相同**；否则 HashSet 会把它们放进不同桶，导致“假重复”——明明该去重却没去成。
常见错误现象：new Person("Alice", 25) 和 new Person("Alice", 25) 被当成两个不同元素存进 HashSet，即使你期望它们是同一个。
- 根本原因：没重写
hashCode()，或重写得不一致（比如只根据name算 hash，但equals()却比较name + age） - 正确做法：只要重写了
equals()，就必须同步重写hashCode()，且逻辑要覆盖所有参与equals()判断的字段 - 推荐用 IDE 自动生成（如 IntelliJ 的
Alt+Insert → equals() and hashCode()），避免手写漏字段或算错
自定义类去重时，hashCode() 写错的典型表现
比如一个 User 类，equals() 比较 id 和 username，但 hashCode() 只基于 id 计算：
public int hashCode() {
return Objects.hash(id); // ❌ 漏了 username
}
后果：两个 User 对象 id 相同但 username 不同，hashCode() 相同 → 进同一桶 → equals() 判定为不等 → 都被加入 HashSet。这违反了“相等对象必须有相同 hash”的契约。
- 性能影响：
hashCode()分布不均会导致大量哈希冲突，退化成链表遍历，add()从 O(1) 变成 O(n) - 兼容性风险：某些 JDK 版本（如 Java 8+）在链表过长时转红黑树，但前提是
hashCode()正确；否则树化后仍可能漏判相等 - 调试建议：在
hashCode()里加日志或断点，确认相同业务意义的对象是否返回相同值
String、Integer 等内置类型为什么直接能去重？
因为它们的 hashCode() 和 equals() 已按规范实现好，且不可变。例如：
-
"hello".hashCode()总是固定值，且所有内容相同的String实例都返回相同 hash -
Integer.valueOf(42).hashCode()就是42，和值强绑定 - 你往
HashSet<string></string>里 add 两次"test"，第二次返回false，说明去重成功
但注意：可变类（如 ArrayList）作元素时，如果后续修改了内容，hashCode() 可能变化，导致集合行为异常（比如再也找不到该元素）——所以别把可变对象当 HashSet 元素，除非你清楚后果。
add() 返回值怎么用？别忽略它的布尔语义
HashSet.add() 返回 boolean：成功加入返回 true，重复元素返回 false。这个返回值不是装饰，是去重逻辑的直接反馈。
- 可用于条件分支：比如只在新增用户时发通知：
if (userSet.add(newUser)) sendWelcomeEmail(newUser); - 不能只看是否抛异常来判断——
add()从不抛异常（除非传null且集合不允许 null） - 注意并发场景：单个
add()是原子的，但“判断是否存在再添加”这种两步操作不是线程安全的，要用ConcurrentHashMap.newKeySet()或加锁
真正容易被忽略的是：很多人以为只要对象进了 HashSet，就“自动永远唯一”，却忘了如果之后修改了对象状态导致 hashCode() 改变，它在集合里的位置就失效了——既查不到，也删不掉，还占着内存。
