对象放入hashset后修改影响hashcode()或equals()的字段会导致contains()、remove()失败，因其哈希定位机制被破坏；根本原因是查找时哈希值与原始存储位置不匹配，故set中对象须逻辑不可变。
这个问题很典型：对象放进 Set（比如 HashSet）后，再修改其影响 hashCode() 或 equals() 的属性，会导致后续 contains()、remove() 失败——元素“凭空消失”，其实还在桶里，只是找不到了。
根本原因：哈希表的定位机制被破坏
HashSet 底层是哈希表，插入时根据对象当前的 hashCode() 决定存到哪个桶；查找时也用当前 hashCode() 去对应桶里找，再用 equals() 确认。一旦对象修改了参与计算哈希值的字段，它的新哈希值和原始存储位置就不匹配了。
- 比如一个
User类用id和name计算hashCode() - 把
user1放进set后，又调用user1.setName("new") - 此时
set.contains(user1)会用新name算哈希，去错的桶里找，自然找不到
关键原则：Set 中的对象必须是不可变的（Immutable）
不是语法上加 final 字段，而是逻辑上——只要它被放入 Set 或作为 Map 的 key，就不要再改任何影响 hashCode() / equals() 的字段。
- 最稳妥做法：把参与
hashCode()和equals()的字段设为final，构造时一次性赋值 - 如果业务确实需要修改，不要直接改原对象，而是移除旧对象、创建新对象、再添加进去
- 避免在
Set中存放可变对象，尤其是那些字段经常变化的 DTO 或实体类
替代方案：用不可变包装或专用结构
若无法避免修改，可绕过哈希查找逻辑：
- 改用
TreeSet（需实现Comparable或传入Comparator），它不依赖hashCode()，靠比较逻辑定位，但修改后仍需确保比较结果一致 - 对小集合，用
ArrayList+ 手动遍历stream().filter().findFirst()，牺牲性能换确定性 - 封装一层：维护一个
Map<key value></key>，Key 是不变的标识（如 id 字符串），Value 是可变对象，所有操作通过 Key 路由
检查与预防：从代码习惯入手
日常开发中可以主动规避：
- 重写
hashCode()和equals()时，只基于final字段或业务上真正“唯一且稳定”的字段（如数据库主键） - IDE 中开启警告：如 IntelliJ 的 “
Mutable object used as key in hash-based collection” 检查 - 单元测试里模拟修改后查找，验证行为是否符合预期
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
