list.copyof不能替代new arraylist(list)，因为它返回不可修改的浅拷贝视图，不支持增删操作，不隔离原列表变更，也不防御元素内部状态被修改。
为什么 List.copyOf 不能直接替代 new ArrayList(list)
它压根不创建可变副本，而是返回一个不可修改的视图——哪怕原列表后续变了，这个副本也不会同步更新，也不允许你调用 add、remove 等任何修改方法，一调就抛 UnsupportedOperationException。
常见错误现象：有人以为“copy”就是深拷贝或独立副本，结果在方法里传入后试图增删元素，运行时炸了；或者误以为它能防御原列表被外部修改，其实它对原列表毫无防护力。
- 只读 ≠ 防御性拷贝：原列表仍可能被其他代码修改，而你的只读副本不会感知，也不会同步
- 性能优势明显：底层复用原数组（Java 11+ 的
List.of和copyOf共享同一份紧凑结构），零拷贝开销 - 要求输入非
null：传null直接抛NullPointerException，不是优雅失败 - 不处理嵌套对象：如果列表里是自定义对象，对象本身仍是引用，改它的字段，副本里看到的也跟着变
什么时候该用 List.copyOf，什么时候不该用
适合场景很明确：你只要「此刻快照 + 绝不允许修改」，比如配置项列表、枚举常量集合、API 返回值封装。
不适合场景同样明确：你需要后续往副本里加数据、排序、过滤再用，或者必须隔离原列表的后续变更影响。
立即学习“Java免费学习笔记（深入）”；
- ✅ 适合：
return List.copyOf(configItems);（防止调用方误改配置） - ✅ 适合：
var snapshot = List.copyOf(currentState);（记录瞬时状态，且确定不改） - ❌ 不适合：
List.copyOf(userInput)后还要.add()或.sort() - ❌ 不适合：原列表本身是动态更新的（如后台线程持续
add），而你需要副本和它保持逻辑一致
List.copyOf 和 Collections.unmodifiableList 的关键区别
两者都返回只读视图，但行为和可靠性差很多。前者是全新不可变实例，后者只是原列表的一层包装。
最易踩的坑：用 Collections.unmodifiableList(new ArrayList(list)) 以为安全，其实中间那个 ArrayList 还活着，别人手里还攥着引用，就能绕过包装直接改。
-
List.copyOf(list)：立即复制内容（浅拷贝），返回真正独立、不可变、不可扩展的对象 -
Collections.unmodifiableList(list)：不复制，只是拦截修改操作；如果传进来的是可变列表，原始引用泄露就等于防线失效 - 兼容性：后者 Java 1.2 就有，前者只在 Java 11+ 可用；但如果你项目已切 Java 11，优先选
copyOf - 空列表处理：
List.copyOf(Collections.emptyList())安全；而Collections.unmodifiableList(null)会 NPE，但List.copyOf(null)同样 NPE，这点一致
如何真正实现「防御性拷贝」——当 List.copyOf 不够用时
只读 ≠ 防御。真要隔绝原列表影响，得确保副本内容独立、且内部元素也不被外部篡改。这时候 List.copyOf 只是第一步。
例如列表里是 Person 对象，你 copy 出来，别人改某个 person.setName("hacked")，副本里的 person 名字一样变。
- 若元素是不可变类型（
String、Integer、LocalDate）：List.copyOf就够用 - 若元素是可变对象：需手动做「深拷贝」，比如用构造函数
new Person(p.getName(), p.getAge())或 record 的with方法 - 别依赖序列化做深拷贝：慢、反射开销大、还可能抛
NotSerializableException - 工具类慎选：Apache Commons Lang 的
SerializationUtils.clone本质还是序列化，同上问题；Guava 的ImmutableList.copyOf行为类似List.copyOf，也不解决元素可变性
真正的防御点永远在元素层级，不是容器层级。很多人卡在这儿，光盯着 list 怎么 copy，忘了里面的东西才是活的。
