list.of 和 map.of 创建的集合不可变，修改抛 unsupportedoperationexception；map.of 限10键值对；list.of 比 arrays.aslist 更安全但语义不同；不可变集合 hashcode/equals 行为需注意。
为什么 List.of 创建的集合不能增删改
因为 List.of 返回的是不可变（immutable）集合，底层不是 ArrayList 或 LinkedList，而是一个私有静态内部实现类（如 ImmutableCollections.ListN），所有修改操作（add、remove、set）都会直接抛出 UnsupportedOperationException。
- 常见错误现象：
Exception in thread "main" java.lang.UnsupportedOperationException出现在调用list.add(...)后 - 使用场景：适合配置项、枚举常量、函数参数默认值等「写后即固定」的数据
- 注意：哪怕只传一个
null元素，List.of(null)也会抛NullPointerException—— 它在构造时就做空值校验
Map.of 最多只能建 10 个键值对？
是的。Map.of 重载方法只提供从 0 到 10 个键值对的版本（Map.of()、Map.of(k1,v1)、…、Map.of(k1,v1, ..., k10,v10)）。超过就得换 Map.ofEntries。
- 常见错误现象：写
Map.of(k1,v1, k2,v2, ..., k11,v11)→ 编译失败，提示“no suitable method found” - 正确做法：用
Map.ofEntries配合Map.entry，例如Map.ofEntries(Map.entry(k1,v1), Map.entry(k2,v2), ...) - 性能影响：两者都返回不可变
Map，但Map.ofEntries多一层数组封装，开销微乎其微，别为这个犹豫
和 Arrays.asList 比，List.of 真的更安全吗
更安全，但安全点不同。Arrays.asList 返回的是可变集合（支持 set，不支持 add/remove），且底层数组引用未隔离；List.of 彻底不可变，也不暴露内部结构。
- 典型坑：
Arrays.asList(arr)返回的 list 修改元素会同步改原数组；List.of(arr)是把整个arr当作一个元素放进 list（除非你显式展开） - 参数差异：
Arrays.asList("a", "b")接受可变参数，但泛型推导弱；List.of("a", "b")泛型更严格，且拒绝null - 兼容性：两者都是 Java 9+ 可用，但
List.of在 Android（API 26+）也支持，Arrays.asList更老，但行为更易误读
什么时候不该用 Map.of 或 List.of
当你要后续修改、或需要保持插入顺序但又不确定 key 是否重复时，别硬套。它们不是语法糖，是语义承诺：「这数据从现在起就不该变了」。
立即学习“Java免费学习笔记（深入）”；
- 容易被忽略的点：不可变集合不重写
hashCode/equals的逻辑缺陷——比如两个内容相同的List.of(1,2)和Arrays.asList(1,2)，equals返回true，但它们的hashCode不同（因底层类不同），用在HashSet或作为HashMapkey 时可能出意料结果 - 如果只是临时组装再立刻传给某个 API，且该 API 内部会拷贝或只读访问，用
List.of没问题；但如果要反复复用、或传入旧代码（可能偷偷修改），先new ArrayList(List.of(...))更稳妥
