HashSet.add()返回true表示元素首次添加成功，false表示元素已存在未插入；常见错误是将true误判为“重复”，正确用法是if(!set.add(id))处理重复。
Java HashSet 在业务开发中用得频繁，但几个关键点一旦疏忽，就容易引发去重失效、逻辑错乱甚至线上事故。避开这些陷阱不靠死记硬背，而在于理解底层机制和明确使用边界。
add() 返回值别反着用
很多人看到 add() 返回 false 就下意识认为“操作失败”或“有重复”，其实它只表达一件事：元素是否被新加入集合。
- true：集合发生了变化，该元素是首次添加
- false：元素已存在，未做任何插入动作
常见错误写法：if (set.add(id)) { /* 处理重复 */ } —— 这里把 true 当成“重复”来处理，逻辑完全颠倒。
正确做法是直接利用返回值判断是否为新数据：if (!set.add(id)) { /* 发现重复，执行拦截或告警 */ }
自定义对象必须重写 hashCode 和 equals
HashSet 判断“重复”的依据不是内存地址，而是先比 hashCode()，再用 equals() 确认。缺一不可。
- 只重写
equals()不重hashCode()→ 同值对象可能散列到不同桶，add()或remove()失效 - 两个逻辑相等的对象返回不同
hashCode()→ 被视为不同元素，导致重复入库 - 对象添加进 HashSet 后修改了影响
hashCode()的字段 → 原位置找不到它，remove()失败，集合状态异常
建议：用 IDE 自动生成，或使用 Objects.hash(...) 和 Objects.equals(...) 保证一致性。
立即学习“Java免费学习笔记（深入）”；
别在遍历时直接修改 HashSet
HashSet 不支持并发修改。用普通 for-each 或增强 for 循环遍历时，调用 set.remove(x) 会触发 ConcurrentModificationException。
- 安全做法：用迭代器的
iterator.remove() - 批量清理：先收集待删元素，循环结束后统一调用
removeAll() - 高并发场景：考虑
CopyOnWriteArraySet（注意写多读少时不适用）
注意 null 元素和线程安全
HashSet 允许存一个 null，但仅限一个。如果业务逻辑依赖 null 表达某种状态，要确保不会意外添加多个或漏判。
- HashSet 本身不是线程安全的；多线程共用同一实例时，必须加锁或改用
ConcurrentHashMap.newKeySet()（JDK 8+ 推荐） - 避免用静态 HashSet 缓存共享状态，尤其在 Spring 等容器管理的 Bean 中，易引发跨请求污染
