Collections.unmodifiableMap仅提供只读视图，无法防止通过原始引用或反射篡改；真正安全需三步：创建独立副本、深度冻结嵌套可变值、套unmodifiableMap并设为static final。
为什么 Collections.unmodifiableMap 不能真正防住篡改
它只是返回一个「只读视图」，底层仍是原 Map 实例。如果下游插件持有原始引用（比如你传参时没做防御性拷贝），或通过反射修改了内部 map 字段，照样能改——这在 Java Agent、字节码增强类库（如 ByteBuddy）或某些框架（Spring AOP 代理逻辑）中很常见。
所以关键不是“套一层 unmodifiable”，而是「切断原始引用 + 阻断可变路径」。
正确初始化全局配置 Map 的三步操作
假设你的核心配置是 Map<string object></string> 类型，且来自 application.properties 或 JSON 初始化：
- 用
new HashMap(source)或Map.copyOf(source)（Java 10+）创建一份**独立副本**，确保不共享底层数组/节点 - 对值做深度冻结：若值是
ArrayList、LinkedHashMap等可变容器，需递归调用Collections.unmodifiableList/Collections.unmodifiableMap；基本类型和String、LocalDateTime等不可变类型可跳过 - 最后套
Collections.unmodifiableMap，并把返回值设为static final，避免被重新赋值
示例：
private static final Map<String, Object> GLOBAL_CONFIG = Collections.unmodifiableMap(
new HashMap<>() {{
put("timeout.ms", 5000);
put("retry.limit", 3);
put("features", Collections.unmodifiableList(Arrays.asList("auth", "cache")));
}}
);
下游插件仍报 UnsupportedOperationException？检查这几个点
这不是 bug，是预期行为，但常因误用触发：
- 插件试图调用
GLOBAL_CONFIG.put(...)、GLOBAL_CONFIG.clear()—— 正确，应抛异常 - 插件拿到的是嵌套的子 map（比如
GLOBAL_CONFIG.get("nested")），而你没对这个子 map 做unmodifiable包装 → 它仍是可变的 - 你用了
Properties加载配置，又直接传给Collections.unmodifiableMap(props)→Properties继承自Hashtable，本身线程安全但可变，必须先转成普通HashMap再包装 - 使用了 Lombok 的
@Builder或 Jackson 反序列化出的 map，默认是可变实现（如LinkedHashMap），没做二次封装
更稳妥的替代方案：用 ImmutableMap（Guava）或 Map.ofEntries（Java 14+）
Collections.unmodifiableMap 是轻量级兜底，但不保证「构造即不可变」。生产环境建议升级：
- Guava 的
ImmutableMap.copyOf(map)：会立即深拷贝键值，且返回对象彻底禁止反射修改（内部用私有构造 + final 字段） - Java 14+ 的
Map.ofEntries(Map.entry(k1,v1), Map.entry(k2,v2))：编译期生成不可变实例，连entrySet()返回的都是只读集合 - 如果配置含嵌套结构，优先用 Jackson 的
ObjectMapper.readValue(json, ImmutableMap.class)，配合模块注册GuavaModule自动转换
注意：Map.of() 最多支持 10 个键值对，超限必须用 Map.ofEntries 或 Guava。
真正难防的从来不是写操作，而是插件通过反射绕过访问控制、或利用 JVM TI 接口 hook 方法入口。如果系统对安全性要求极高，得配合 SecurityManager（已弃用）或 JVM 启动参数 -XX:+EnableJVMCI + 自定义 class transformer，但这已超出 unmodifiableMap 能力边界。
