Collections.unmodifiableMap仅提供只读视图，无法防止底层Map被篡改；必须传入副本（如new HashMap(raw)），并配合不可变配置类、深拷贝嵌套对象及JDK9+ Map.copyOf()等手段才能真正防篡改。
为什么 Collections.unmodifiableMap 不能真正防住篡改
它只是给原 Map 套了一层只读外壳，底层引用没变。如果下游拿到的是你传入的原始 HashMap 实例，或者你返回前没切断所有可变引用，配置照样会被改掉。
常见错误现象：UnsupportedOperationException 没抛出来，但配置值在某个业务线程里悄悄变了；或者日志里看到 key 对应的 value 突然变成 null 或其他值。
- 必须确保传入
unmodifiableMap的是**副本**，不是原始配置容器 - 不要把原始
Map实例保存在任何 public/static 字段或 setter 参数里 - 如果配置本身含可变对象（比如
ArrayList值），只封 Map 不够，还得深拷贝那些值
正确初始化：用 new HashMap(source) 切断引用
别直接包装 Spring 的 @ConfigurationProperties 对象、YamlPropertySourceLoader 解析出的 Map，或任何外部注入的 map —— 它们大概率是你自己持有的可变实例。
实操建议：
- 从配置源加载后，立刻构造新
HashMap：new HashMap(rawConfigMap) - 再套
Collections.unmodifiableMap：Collections.unmodifiableMap(new HashMap(rawConfigMap)) - 如果配置是嵌套结构（比如 value 是
Map或List），需递归封装，或改用ImmutableMap.copyOf()（Guava）
示例：
Map<String, Object> safeConfig = Collections.unmodifiableMap(
new HashMap<>(applicationConfigMap)
);
配合 final + private + getter 封装成配置类更可靠
单独靠 unmodifiableMap 容易漏掉字段暴露、getter 返回内部引用等问题。推荐封装为不可变配置类。
- 字段声明为
private final Map<string string></string> - 构造时传入已封装好的
unmodifiableMap -
getXXX()方法直接返回该字段，不加任何逻辑 - 避免提供
asMap()这类“裸露”方法；如必须提供，确保返回的是新封装结果，而非缓存字段
这样比裸用 unmodifiableMap 多一层封装意图和访问控制。
注意 JDK 版本差异和替代方案
JDK 9+ 提供了 Map.of() 和 Map.copyOf()，它们创建的是真正不可变实现（非装饰器），且 copyOf 会做防御性拷贝：
-
Map.copyOf(original)在 original 是不可变 map 时直接返回它；否则新建不可变副本 - 比
Collections.unmodifiableMap更安全，尤其适合配置初始化场景 - 但不支持 null key/value（
unmodifiableMap允许）—— 如果你的配置含 null，得先清洗
如果项目已引入 Guava，ImmutableMap.copyOf() 是更稳妥的选择，它会递归冻结嵌套集合。
真正难防的不是下游调 put，而是他们持有原始引用、或通过反射/序列化/第三方库绕过封装。所以关键不在“用哪个 API”，而在整个配置生命周期里有没有守住那几处可变入口点。
