collections.unmodifiablemap仅包装不复制，原始map被修改则视图同步变化；需传入独立副本或改用guava immutablemap实现真正不可变。
用 Collections.unmodifiableMap 后还是能改？检查底层是否被共享
直接结论：Collections.unmodifiableMap 只挡接口调用，不复制数据。如果原始 Map 还在别处被持有并修改，不可变视图里的内容会同步“变”——这不是 bug，是设计使然。
常见错误现象：封装返回值时只包了一层 unmodifiableMap，但构造前用的是同一个可变 HashMap 实例，外部一改，返回的“不可变” Map 就跟着变了。
- 必须确保传入
Collections.unmodifiableMap的是**独立副本**，比如先new HashMap(original) - 如果原始
Map是类字段，且该类其他方法还能访问它，那unmodifiableMap没意义 - 嵌套结构更危险：value 是可变对象（如
ArrayList）时，外层不可变，内层照旧能改
替代方案：Guava 的 ImmutableMap 更彻底
Collections.unmodifiableMap 是 JDK 原生轻量方案，但不做深拷贝、不校验 null、不冻结 value 对象；ImmutableMap（来自 Guava）默认深冻结、构建即不可变、线程安全，更适合防御性编程场景。
使用场景：配置加载、常量映射、DTO 返回字段封装等需要强保证的地方。
-
ImmutableMap.of("k", "v")和ImmutableMap.copyOf(map)都会立即复制键值，切断源头引用 -
ImmutableMap.builder()支持链式构建，比反复 new + put + unmodifiable 更简洁 - 注意：Guava 21+ 要求 key/value 不能为
null，而Collections.unmodifiableMap允许（只要原 map 允许）
泛型擦除导致的运行时类型绕过风险
Java 泛型在运行时不存在，所以即使你声明了 Map<string integer></string>，实际传给 Collections.unmodifiableMap 的可能是 Map<object object></object>。编译器不报错，但运行时可能抛 ClassCastException。
典型出错点：把非泛型 map 强转后塞进去，或者用反射往不可变 map 里塞非法类型。
- 避免裸写
(Map) someRawMap，优先用带泛型的构造方式 - 如果必须接收原始类型，加一层
instanceof校验或用Objects.requireNonNull配合泛型工具方法 - IDE 提示 “Unchecked cast” 时别点忽略——这里就是容易漏掉的类型漏洞点
性能和兼容性：小数据用 unmodifiableMap，大数据或高并发选 ImmutableMap
Collections.unmodifiableMap 几乎零开销，只是包装一层代理；ImmutableMap 构建时要复制、排序、生成哈希表，有明显 CPU 和内存成本。
但反过来，ImmutableMap 的 get 操作更快（优化过的查找逻辑），且多线程读取完全无锁；unmodifiableMap 虽然也线程安全读，但底层仍是普通 HashMap，并发写仍会破坏一致性。
- 单次构建、多次读取、数据量 unmodifiableMap 足够
- 需保证构建后绝对不可篡改，或跨线程高频读 → 选
ImmutableMap - JDK 10+ 可考虑
Map.copyOf（返回不可变视图），但仅限Map接口实现，且不支持自定义 key/value 类型约束
最常被忽略的其实是 value 的可变性：哪怕 key 和 map 结构锁死了，value 是个 ArrayList 或自定义 POJO，别人照样能改里面的内容。防御性编程真要到位，得一层层看住引用链。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
