List.of()和Map.of()创建的集合不能add/remove，因为它们返回JVM内置不可变实现类（如ListN、MapN），所有修改操作均直接抛UnsupportedOperationException；不支持null、有参数数量限制（List.of最多10个）、Map.of重复key在Java 14+编译期报错；适用于配置项、映射表等只读场景，但不防元素内部可变。
为什么 List.of() 和 Map.of() 创建的集合不能 add/remove
因为它们返回的是 JVM 内置的不可变实现类（如 ListN、ImmutableCollections.MapN），底层直接抛出 UnsupportedOperationException，不是靠封装或代理拦截。调用 add()、put()、clear() 等任何修改方法都会立即失败，而不是静默忽略或延迟报错。
常见错误现象：在 service 层返回了 List.of(user1, user2)，但 controller 层试图 list.add(newUser) —— 运行时直接炸，堆栈里能看到 java.lang.UnsupportedOperationException。
- 只适用于数据确定后就不再变更的场景，比如配置项列表、HTTP 响应码映射表、枚举别名字典
- 不支持
null元素：List.of(null)和Map.of("k", null)都会抛NullPointerException - 元素个数上限：
List.of()最多支持 10 个参数，超了得用List.ofArray(new String[]{...})（Java 14+）或退回到Collections.unmodifiableList()
Map.of() 的键冲突和重复值怎么处理
Map.of("a", 1, "b", 2, "a", 3) 会在编译期报错（Java 14+），不是运行时报错；而 Map.ofEntries() 在运行时检测到重复 key 才抛 IllegalArgumentException，提示 “duplicate key: a”。这点很关键——它让问题暴露得更早。
使用场景上，适合定义固定结构的映射关系，比如：
Map<String, Integer> statusMapping = Map.of(
"CREATED", 100,
"PROCESSING", 200,
"COMPLETED", 300
);
- 如果业务需要允许重复 key（比如多值映射），别硬套
Map.of()，改用Map.ofEntries(Map.entry("k", v1), Map.entry("k", v2))不行——它仍不允许重复 key；此时应选ImmutableMultimap（Guava）或自己封装 -
Map.ofEntries()是唯一能构造含空格/特殊字符 key 的方式（比如Map.entry("user-id", 123)），Map.of()的参数必须是合法标识符形式
不可变集合真的“绝对安全”吗
不。它们防的是集合结构被修改，但不防元素对象自身被改。比如 List.of(new User("Alice"))，虽然 list 不能 add/remove，但 list.get(0).setName("Bob") 依然生效——前提是 User 是可变类。
所以真正防篡改要分两层：
- 集合容器层：用
List.of()/Map.of()封住增删改结构操作 - 元素内容层：确保元素类型本身不可变（如用
record、final字段 + 无 setter 的 POJO，或手动 deep copy） - 如果元素是数组或
java.util.Date这种典型可变类型，即使放进List.of()，外部仍可通过引用修改其内容，必须额外防御性拷贝
什么时候不该用 List.of() / Map.of()
当集合需要动态增长、按需过滤、或与旧代码（尤其是依赖 ArrayList 特定行为如 ensureCapacity()）交互时，强行用不可变集合反而增加复杂度。
典型踩坑点：
- MyBatis 返回结果被包装成
List.of()后传给前端分页工具，结果工具内部调用了subList()或sort()—— 报UnsupportedOperationException，因为ListN不支持这些操作（Java 16 前） - Spring Boot 的
@ConfigurationProperties绑定字段声明为List<String>，但初始化用了List.of()，会导致后续 refresh 配置失败（框架尝试 clear/re-add） - 日志框架（如 Logback）对集合做 toString() 时，某些版本对不可变集合的格式化有兼容问题，输出类似
ListN@1a2b3c而非实际内容
不可变性的价值不在“永远不用改”，而在“改必须显式发生”。一旦你意识到某处数据本就不该被下游改动，List.of() 和 Map.of() 就是最轻量、最直接的契约表达——但得清楚它守的是哪条线，又在哪留了门。
