应优先用 List.copyOf 确保底层数据彻底不可变，它复制新列表并返回 JDK 10+ 内置不可变实现；Collections.unmodifiableList 仅包装视图，原始列表变更会影响视图。
什么时候该用 List.copyOf 而不是 Collections.unmodifiableList
当你要确保底层数据彻底不可变、且不希望调用方通过任何方式篡改原始集合时，优先选 List.copyOf。它不只是加个“只读壳”，而是真复制一份新列表——哪怕传入的是可变的 ArrayList，返回的也是内部不可变的实现（JDK 10+ 的 ImmutableCollections.ListN）。
而 Collections.unmodifiableList 只是包装一层视图，如果原始列表后续被其他代码修改，这个“只读视图”会同步反映变化（甚至抛 ConcurrentModificationException），这不是真正的只读语义。
- 场景举例：方法返回内部状态时，你不想暴露可变引用 → 用
List.copyOf - 场景举例：接收外部传来的
List做缓存，怕别人偷偷改了原列表 → 用List.copyOf - 场景举例：只是临时禁止某段逻辑修改某个已有列表，且你完全控制原始列表生命周期 →
Collections.unmodifiableList足够轻量
List.copyOf 的 null 安全和空集合处理
List.copyOf 对 null 输入直接抛 NullPointerException，这点比 Collections.unmodifiableList 更严格（后者接受 null 并在访问时才炸）。所以用之前必须自己判空，或者明确知道输入非空。
但它对空集合很友好：List.copyOf(Collections.emptyList()) 返回的是一个真正不可变、不可序列化的空列表（ImmutableCollections.List0），内存占用极小；而 Collections.unmodifiableList(new ArrayList()) 返回的仍是基于可变 ArrayList 的包装类，有额外对象开销。
立即学习“Java免费学习笔记（深入）”；
- 常见错误：直接传
null给List.copyOf→ 立刻NullPointerException - 建议写法：
List.copyOf(list != null ? list : List.of())或提前校验 - 注意：即使
list是Arrays.asList(...)这种固定大小的，List.copyOf也会复制，断开与原数组的联系
性能与兼容性差异：JDK 版本和 GC 压力
List.copyOf 是 JDK 10 引入的，低于这个版本无法使用；Collections.unmodifiableList 自 JDK 1.2 就存在，兼容性无压力。
性能上，List.copyOf 多一次数组拷贝，但换来的是更确定的行为和更低的运行时风险；Collections.unmodifiableList 几乎零开销，但把责任全推给调用方——比如你传了个被多线程共享的 ArrayList，它就可能出竞态问题。
- GC 影响：大量调用
List.copyOf（尤其大列表）会增加短期对象分配，注意监控 - 序列化行为不同：
List.copyOf返回的不可变列表默认不可序列化（抛NotSerializableException），而Collections.unmodifiableList包装的对象仍可序列化（如果原列表可序列化） - 反射绕过？两者都挡不住反射暴力修改，但
List.copyOf至少没留“后门引用”
别以为用了 List.copyOf 就万事大吉
它只保证列表结构不可变（不能 add/remove/set），不保证元素本身不可变。如果列表里存的是可变对象（比如 new Person("Alice")），别人依然能调用 person.setName("Bob") ——这跟列表无关，是元素设计的问题。
另外，List.copyOf 不递归冻结嵌套结构。比如 List.copyOf(List.of(new ArrayList()))，外层是不可变的，但里面的 ArrayList 还是活的。
- 容易忽略的点：只读列表 + 可变元素 = 表面安全，实际仍有状态泄漏风险
- 如果你需要深度不可变，得配合不可变元素类型（如
String、LocalDateTime）或手动深拷贝 - IDE 或静态检查工具（如 ErrorProne）能帮你发现部分误用，但不会自动拦截元素层面的变异
