核心原因是保证hashCode()值恒定不变：key可变会导致哈希值变化，使HashMap查找时定位到错误桶，造成“静默丢失”；String等不可变类因final字段和哈希缓存确保该值始终一致。
Java HashMap 中 Key 必须用不可变对象，核心原因就一个：保证 hashCode() 值在生命周期内恒定不变。一旦 key 可变，修改内容后哈希值变化，HashMap 就再也找不到它——不是删除了，而是“静默丢失”，查不到也报不了错，极难排查。
避免哈希桶错位导致查找失败
HashMap 用 key 的 hashCode() 决定存到哪个桶（数组索引）。如果 key 是可变的，比如你把一个自定义对象作为 key 放进去，之后调用 setter 修改了影响 hashCode 的字段，它的哈希值就变了。但 HashMap 还按老哈希值去旧桶里找，自然返回 null。String、Integer 等天然不可变，byte[]/char[] 或 int 值被 final 修饰，内容一确定就再不能改，hashCode 也就永远稳定。
- 例如：
map.put(new String("user"), "data")，之后若能改字符串内容为 "USER"，hashCode 就不同了（实际不可能，因为 String 不可变） - 而可变类如
MutableKey，字段改了、hashCode 变了，map.get() 就永远 miss
利用哈希码缓存提升高频操作性能
String 的 hashCode() 是懒计算 + 缓存的：首次调用才算，结果存在私有字段里，后续直接返回。这对 get()、containsKey() 这类高频操作是实打实的优化。如果每次都要重新计算（比如对含深遍历逻辑的可变对象），性能损耗明显，尤其在缓存、路由、配置中心等场景下会拖慢整个链路。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 对比：String 的 hashCode 缓存是 JVM 层面内置保障；自己写的可变 key 得手动加 final 字段+构造时预计算，否则容易漏
- 不缓存的 hashCode 方法，在 Map 频繁读写时可能成为瓶颈
防止内存泄漏与隐式强引用陷阱
Map 的 key 是强引用。如果拿一个大业务对象（比如含 10 个字段的 User 实例）当 key，只要这个 Map 还活着，GC 就不敢回收它——哪怕 value 已设为 null，哪怕你再也不 get 它。更麻烦的是，如果其他模块还持有该对象引用，又没及时 remove，它就会一直卡在 Map 里，jmap -histo:live 一眼就能看到堆积。
立即学习“Java免费学习笔记（深入）”；
- 不可变对象通常轻量（String、Long、Integer），本身内存占用小，复用率高（如 String Pool）
- 大对象作 key 还带来哈希计算开销大、equals 默认比引用而非内容、跨模块清理耦合等问题
天然支持线程安全与并发稳定性
不可变性意味着线程间共享无需同步。多个线程同时用同一个 String 作 key 去 get 或 put，不会因 key 状态改变引发竞争或数据错乱。而可变 key 在并发场景下，可能一个线程刚算完 hashCode，另一个线程就改了字段，结果哈希不一致，get 返回 null 或覆盖错误位置——这种 bug 很难复现，更难定位。
- ConcurrentHashMap 虽支持并发，但前提是 key 自身行为稳定；key 可变会绕过并发控制机制
- 不可变 key + 正确重写的 equals，是线程安全 Map 使用的基础前提
