list.of 和 map.of 是 java 9 引入的不可变集合工厂方法，不支持 null 元素或键值，返回私有不可变类实例，调用 add/remove 抛 unsupportedoperationexception；适用于默认参数、配置项、测试断言等只读场景。
List.of 和 Map.of 是 Java 9 引入的不可变集合工厂方法，不是“字面量”，也不支持 null 元素或键值 —— 这是绝大多数人踩坑的第一步。
为什么 List.of 创建的集合不能 add/remove
它返回的是 JVM 内部实现的私有不可变类（比如 ImmutableCollections.ListN），所有修改操作都直接抛 UnsupportedOperationException。这不是限制，而是设计契约：一旦创建，生命周期内结构与内容必须固定。
常见错误现象：
- 调用
list.add("x")报错：java.lang.UnsupportedOperationException - 试图用
ArrayList构造器包装它再修改：new ArrayList(List.of(1,2))—— 可行，但已脱离“不可变”语义，别混淆目的
使用场景：
立即学习“Java免费学习笔记（深入）”；
- 作为方法参数默认值（避免被意外修改）
- 配置项、枚举常量集合等只读数据容器
- 单元测试中构造预期结果集（断言时不怕被副作用污染）
Map.of 对 key 和 value 的 null 限制很严格
Map.of() 在 Java 9–14 中完全禁止 null 键和 null 值；Java 15+ 才通过 Map.ofEntries(Map.entry(k,v)) 绕过（但 entry 本身仍不接受 null）。这点和 HashMap 或 Map.ofNullable（Java 19+）有本质区别。
容易踩的坑：
-
Map.of("a", null)直接编译失败（JDK 14 及以前）或运行时报NullPointerException - 误以为
Map.of("k1","v1","k2",null)能“跳过”第二对 —— 实际会立即中断，不构造任何 map - 在 Spring Boot 配置类里硬写
Map.of("timeout", env.getProperty("api.timeout"))，而该属性为空时崩掉
替代方案（按 JDK 版本）：
- JDK 9–14：
Map.ofEntries(Map.entry("k1","v1"))（仍不能含 null） - JDK 19+：
Map.ofNullable("k1", null)（允许单个 null 值，但 key 仍不可为 null） - 通用兜底：
Collections.unmodifiableMap(new HashMap(){...})，自己判空再 put
性能与兼容性：小集合快，大集合别硬套
List.of 和 Map.of 的底层做了高度特化：元素少时用栈内对象（如 List1, Map2），无迭代器开销、无扩容逻辑，比 new ArrayList(Arrays.asList(...)) 快 2–3 倍。但超过 10 个元素后，可读性和维护性迅速下降。
参数差异带来的实际影响：
-
List.of(1,2,3)最多支持 10 个参数；超了必须用List.ofArray(new Integer[]{...})（Java 10+） -
Map.of("a",1,"b",2)同样限 10 个参数（即 5 对）；更多请改用Map.ofEntries(entry1,entry2,...) - 所有参数在调用时求值 —— 如果传入的是耗时计算或有副作用的表达式（如
service.fetch()），失败则整个构造失败，没有“部分成功”概念
真正麻烦的不是语法，是思维切换：它们不是语法糖，而是契约型 API。你得提前决定“这个集合要不要被改”，而不是先创建再补防御。一旦选了 List.of，就等于签了不可变协议 —— 后续所有协作代码都得按这个前提来。
