hashmap的key必须使用不可变对象，因哈希表依赖稳定的hashcode()和equals()定位键值对；若key可变，修改后哈希值或比较逻辑变化会导致get时定位错误桶或匹配失败，引发静默数据丢失。
Java 中 HashMap 的 key 必须使用不可变对象，不是“推荐”，而是底层机制决定的硬性要求。一旦违反，会导致 数据静默丢失——put 进去了，get 却拿不到，且不报错、不抛异常，极难排查。
哈希表查找依赖稳定的 hashCode 和 equals
HashMap 底层是数组 + 链表/红黑树。它靠 key 的 hashCode() 定位桶（bucket），再用 equals() 在桶内精确匹配。
- 插入时：计算 key.hashCode() → 找到数组索引 → 存入该位置
- 查找时：再次计算 key.hashCode() → 去同一个索引找 → 用 equals() 确认是不是原 key
如果 key 可变，修改后 hashCode() 变了，get() 就会去错的桶里翻找，自然找不到；即使哈希值没变，但 equals() 判断逻辑因字段变化而失效，也会匹配失败。
可变 key 的典型风险场景
- 只改一个参与 equals/hashCode 计算的字段，就足以让键值对“消失”
- 多线程下更危险：线程 A 刚 put，线程 B 立刻修改 key 内容，后续所有 get 都失败
- 常见踩坑写法：
new StringBuilder("a")、普通 POJO 类（如未加 final 和重写方法的 User）、AbstractMap.SimpleEntry
安全自定义 key 的三个必要条件
-
不可变性：所有用于 equals/hashCode 的字段必须是
final，不提供 setter，不暴露可变引用（如 ArrayList） -
正确重写 hashCode()：用
Objects.hash(f1, f2)等标准方式，确保内容相同则哈希值必然相同 -
正确重写 equals()：用
Objects.equals()处理 null，比较字段必须与 hashCode 中完全一致、顺序一致
为什么 String、Integer 是天然好选择
它们本身就被设计为不可变类，并已正确重写 hashCode() 和 equals()：
- String 缓存了哈希值，重复计算零开销
- Integer 等包装类字段是 final，无修改入口
- 语义清晰：“内容相等”即逻辑相等，符合日常直觉
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
