修改key字段导致get()或remove()失效是哈希表机制决定的必然结果：key.hashcode()改变后桶位置偏移，但entry仍留在原桶，后续查找去新桶为空。
直接在 entrySet() 迭代中修改 key 对象的字段，会导致后续 get() 或 remove() 失效——这不是偶然 bug，而是哈希表机制决定的必然结果。
为什么改 key 字段会让 Map “找不到自己”
HashMap 查找依赖两个固定环节：先用 key.hashCode() 算出桶位置，再在该桶内用 equals() 匹配具体 Entry。一旦 key 对象的字段被修改（且这些字段参与了 hashCode() 计算），哈希值就变了，但 Entry 仍留在原来的桶里。下次 get() 会去新哈希值对应的桶里找，自然为空。
- 比如存入
new User(1001, "Alice")，id和name都参与hashCode() - 之后调用
user.setName("Bob")，哈希值改变 -
map.get(user)返回null，哪怕user.equals()仍能对上
如何快速确认是否发生了哈希漂移
别急着重写逻辑，先验证哈希值是否变动：
- 存入前打印
key.hashCode()，记下数值（如142857） - 修改字段后立即再打一次（如变成
987654） - 两值不同 → 基本可断定是哈希漂移导致查找失败
- 调试时也可观察
map.table[index]对应桶，看原 Entry 是否还在旧位置
entrySet 迭代中修改 key 的风险远不止 get 失效
在 for (Map.Entry<k> entry : map.entrySet())</k> 循环里，若通过 entry.getKey() 拿到 key 并修改其字段，问题会叠加：
- 当前 Entry 的
getKey()返回仍是原对象，但它的哈希已变 - 后续遍历中其他 Entry 可能因 rehash 被移动，迭代顺序错乱
- 若此时调用
map.remove(key)，也会因哈希不匹配而删不掉 - 多线程下更危险：一个线程刚 put，另一个线程改 key 字段，整个 Map 查找逻辑崩坏
真正安全的应对方式
不是禁止修改，而是让修改不破坏哈希一致性：
- 只用不可变字段参与
hashCode()和equals()，例如 User 类中仅id影响哈希，name、email改了也不影响定位 - 封装不可变包装类，如
UserId(id)，所有字段final，hashCode()完全基于它 - 业务需要“更新 key”，走显式替换：
map.remove(oldKey); map.put(newKey, value) - 运行时加防护：在 setter 中检查该实例是否已在 Map 中注册为 key，是则抛
IllegalStateException
优先选用 JDK 自带不可变类型作 key：String、Integer、UUID、LocalDate —— 它们天然稳定，不用额外防护。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
