HashSet.add()返回false表示元素已存在、未插入，true才表示首次添加成功；常见误将true当作重复处理，正确逻辑应为if(!set.add(id))拦截重复。
HashSet 本身不会主动“报错”，但业务中常因误用触发运行时异常、逻辑错误或隐蔽失效。排查重点不在堆栈本身，而在理解底层行为与使用边界。下面分四类典型问题说明排查路径和关键动作。
add() 返回 false 却以为添加成功
这是最易被忽略的逻辑反向错误。add() 返回 false 表示元素已存在、未插入；返回 true 才是首次加入。若把 true 当作“重复”处理，整个去重流程就全反了。
- 检查代码中是否写了 if (set.add(id)) { /* 处理重复 */ } —— 这是典型误判，应改为 if (!set.add(id)) { /* 拦截/告警/跳过 */ }
- 打印返回值验证：对同一对象连续 add 两次，确认第一次为 true、第二次为 false
- 注意 null 值：add(null) 在 HashSet 中是合法的（除非你额外校验），且 null 的 hashCode 固定为 0，equals 判定也特殊，别让它混入业务主键逻辑
自定义对象重复添加，去重失效
根本原因是 equals 和 hashCode 未协同生效。HashSet 查找时先算哈希桶，再桶内 equals；缺一环就失效。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 确认类是否重写了 两个方法：只重 equals 或只重 hashCode 都不行
- 检查重写内容：参与计算的字段必须完全一致（如 name + age），且不能含可变字段（比如后续会 setXXX 修改的属性）
- 快速验证：新建两个内容相同的对象，分别打印 hashCode()，再调用 equals() —— 两者都需返回 true；若 hashCode 不同，说明重写有漏或用了默认实现
- 推荐用 IDE 自动生成，或直接用 Objects.hash(name, age) 和 Objects.equals(a, b)，避免手写疏漏
remove() 返回 false，对象却还在集合里
不是内存泄漏，而是“找不着人”——对象存进去后改了影响 hashCode 的字段，导致 remove 时去错了桶位。
- 回溯代码：对象加入 HashSet 后，是否调用了 setter 修改了 name、id、status 等参与哈希计算的字段？这是最高发原因
- 调试技巧：在 remove 前后分别打印该对象的 hashCode()，对比是否变化；再遍历集合，手动调用 obj.equals(待删对象)，看是否有逻辑相等但 hashCode 不同的“幽灵对象”
- 修复方向：要么让参与哈希的字段 final（构造即定），要么修改前先 remove、改完再 add（注意并发安全）
类型强转异常：HashSet cannot be cast to List
这是编译期不报错、运行时报 ClassCastException 的经典案例，本质是混淆了集合接口层级。
- 明确一点：HashSet 实现的是 Set 接口，和 List 完全无关，二者没有继承或实现关系
- 常见诱因：从 Map.values() 拿到 Collection，误以为是 List 就强转；或第三方 API 文档没看清返回类型
- 正确做法：需要 List 时，用 new ArrayList(set) 或 set.stream().toList()（Java 16+）转换，而不是强制转型
- IDE 提示可辅助识别：鼠标悬停变量名，看实际类型是不是 HashSet；开启泛型警告能提前发现擦除风险
