HashSet 元素变动陷阱：分析修改变量属性导致 hashCode 改变而无法删除的风险-java教程-PHP中文网

修改影响 hashCode() 的字段会导致 remove() 静默失败，因为 HashSet 基于 HashMap 实现，元素位置由插入时哈希值固化决定，后续删除按新 hashCode() 查找桶位，但对象仍在原桶，导致查找不到而返回 false。

hashset 元素变动陷阱：分析修改变量属性导致 hashcode 改变而无法删除的风险

对象放进 HashSet 后，如果修改了影响 hashCode() 计算的字段，会导致 remove() 失败——不是方法报错，而是静默失效。根本原因在于：HashSet 底层用 HashMap 实现，元素位置由插入时计算出的哈希值决定，且该值被固化在内部节点中；后续操作（包括删除）仍按当前对象的 hashCode() 去查找桶位，但此时桶位已错位。

为什么改属性会让 remove 失效

HashSet 不是靠遍历比对来删元素，而是：

调用你要删的对象的 hashCode()，算出它“应该在哪个桶”
去那个桶里找，再用 equals() 确认是不是同一个对象
但你改过属性后，hashCode() 变了，“应该在的桶”就不是它实际存放的位置
结果：桶里空空如也，remove() 返回 false，对象还在集合里

典型触发场景

以下写法看似自然，实则危险：

用 @Data（Lombok）修饰实体类，字段可变 + 自动生成 hashCode() 和 equals()
把 Person 对象加入 HashSet，之后调用 person.setName("new")
把 HashMap 或 ArrayList 当作 HashSet 元素，又修改其内容（它们的 hashCode() 依赖内部状态）
自定义类重写了 hashCode()，但用了可变字段（比如 id、name、status）参与计算

安全做法推荐

不靠“记得别改”，而靠设计防错：

优先用不可变对象作元素：字段 final，构造即定型，hashCode() 和 equals() 只依赖不变量
若必须修改，走“删–改–加”流程：先 set.remove(oldObj)，再改字段，最后 set.add(newObj)（注意：oldObj 和 newObj 是同一引用，改完再加也行，但前提是确保 remove 成功）
慎选参与 hash 计算的字段：只用业务上真正“标识身份”的、不会变的字段（例如数据库主键 id），避开 name、email、updatedAt 等易变字段
特殊场景可用 IdentityHashMap：它不依赖 hashCode()/equals()，而是按内存地址判断，适合临时调试或明确需引用语义的场合