修改影响 hashCode() 的字段会导致 remove() 静默失败，因为 HashSet 基于 HashMap 实现，元素位置由插入时哈希值固化决定，后续删除按新 hashCode() 查找桶位，但对象仍在原桶，导致查找不到而返回 false。
对象放进 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()，而是按内存地址判断，适合临时调试或明确需引用语义的场合
如何快速发现这类问题
日常开发中可关注这些信号：
-
set.remove(obj)返回false，但你确定它就在集合里 - 反复
add(obj)同一个对象，size()却持续增长 - 日志或调试中看到同一逻辑对象的
hashCode()值前后不一致 - 使用 IDE 的 “Find Usages” 查看某字段是否被
hashCode()引用，再确认该字段是否可能被外部修改
