Collections.unmodifiableList仅提供只读视图，不复制底层集合，原始列表被修改时视图内容随之变化；需配合防御性拷贝或确保原始引用不外泄才能真正保护数据。
为什么 Collections.unmodifiableList 不能真正阻止原始集合被修改
它只提供一个“只读视图”，底层仍指向原 List。如果原始列表（比如 ArrayList）在别处被修改，这个不可修改包装器读到的内容也会变——这不是 bug，是设计使然。
常见错误现象：UnsupportedOperationException 只在调用 add、remove、set 等写操作时抛出；但若原始列表被其他引用改了，get(0) 返回的值可能已不同。
- 使用场景：适合封装返回值，防止调用方意外修改返回的列表
- 不适用场景：需要彻底隔离数据变更（比如多线程共享或需防御性拷贝）
- 关键点：它不复制元素，也不冻结原始对象
正确用法：必须确保原始列表不再被外部持有可变引用
否则保护形同虚设。典型安全做法是创建后立刻丢弃原始引用，只暴露包装后的不可修改版本。
List<String> original = new ArrayList<>(Arrays.asList("a", "b", "c"));
List<String> safeView = Collections.unmodifiableList(original);
original.clear(); // ⚠️ 还能调！safeView.size() 变成 0
应改为：
List<String> safeView = Collections.unmodifiableList(
new ArrayList<>(Arrays.asList("a", "b", "c"))
);
- 构造时传入新实例（如
new ArrayList(source)），切断外部对原始容器的引用 - 如果 source 本身已是不可变或确定不会再被修改，可跳过拷贝，但需代码审查确认
- 注意：元素对象本身是否可变（如
Person对象的字段）不受此保护，那是另一层问题
替代方案对比：什么时候该用 Arrays.asList + unmodifiable，什么时候用 ImmutableList.of
Collections.unmodifiableList(Arrays.asList(...)) 是 JDK 原生做法，但写法啰嗦且仍依赖数组底层数组可变（Arrays.asList 返回的是固定大小的 ArrayList 子类，不支持 add/remove，但支持 set）。
Guava 的 ImmutableList.of 或 ImmutableList.copyOf 更彻底：元素不可变、大小不可变、连 set 都不支持，且默认深拷贝引用（不拷贝对象内容）。
- JDK 方案：轻量、无依赖，但需手动防御原始引用泄露
- Guava 方案：语义更清晰、更难误用，但引入第三方依赖
- Java 10+ 可考虑
List.copyOf（返回不可变副本），但要求源列表不能为null且不接受null元素
容易踩的坑：嵌套可变对象和并发访问
即使列表本身不可修改，里面存的仍是普通对象引用。比如 List<StringBuilder> 包装后，仍可调用 get(0).append("x") 修改内部状态。
并发下更危险：Collections.unmodifiableList 不提供线程安全保证。原始列表若被多个线程并发修改，即使只读视图不抛异常，也可能读到部分更新的中间状态（如 ConcurrentModificationException 或脏读）。
- 防御嵌套可变：要么确保元素类型不可变（如
String、LocalDateTime），要么在放入前做浅拷贝 - 防御并发：需配合同步机制（如
synchronized块）、使用CopyOnWriteArrayList，或改用java.util.concurrent中的线程安全集合 - 最常被忽略的一点：开发者以为加了
unmodifiableList就“万事大吉”，结果在别处悄悄改了原始列表，调试时完全想不到那里
