Collections.unmodifiableList返回的是实时反映原始列表改动的“活镜像”，而非快照；它通过委托读操作、拦截写操作实现只读视图，但不复制数据或冻结源头，因此原始列表被add、set、clear时，视图同步变化。
它不是快照，是活的镜像——Collections.unmodifiableList 返回的列表会实时反映原始列表的任何改动，这是设计本意，不是缺陷。关键在于理解“只读”仅约束操作入口，不冻结数据源头。
为什么修改原始列表，只读视图立刻“变”了？
unmodifiableList 不复制元素，也不克隆结构，它只是把 get()、size()、iterator() 等读方法委托给底层原始 List；所有写方法（add、remove、set、clear）则统一拦截并抛 UnsupportedOperationException。因此：
- 原始列表被其他代码
add("X")→ 只读视图get(2)能取到 "X" - 原始列表被
set(0, "Y")→ 只读视图get(0)返回 "Y" - 原始列表被
clear()→ 只读视图size()立刻变成 0
典型动态可见性演示代码
下面这段代码清晰展示“视图随源动”的行为：
List<String> source = new ArrayList<>(Arrays.asList("a", "b"));
List<String> ro = Collections.unmodifiableList(source);
System.out.println(ro); // [a, b]
source.add("c"); // 修改原始列表
System.out.println(ro); // [a, b, c] ← 视图同步更新！
source.set(1, "B"); // 再改一个元素
System.out.println(ro); // [a, B, c] ← 还是同步！
// 下面这行会立即抛 UnsupportedOperationException
// ro.add("d");
如何切断动态联动，实现真正隔离？
要让只读视图不再受原始列表牵连，必须在包装前“断开引用链”。核心思路是：先做一份独立副本，再包装。常用做法包括：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
-
Java 10+：用
List.copyOf(source)—— 它自动创建不可变副本，且拒绝 null 元素 -
兼容老版本：用
new ArrayList(source)浅拷贝，再套Collections.unmodifiableList(...) - 构造时即隔离：若原始数据来自参数，应在接收时就拷贝，避免后续被污染
错误示范：Collections.unmodifiableList(Arrays.asList(...)) —— 因为 Arrays.asList 返回的是数组的直接视图，底层仍可被 set() 修改，且无法 add/remove，语义混乱。
嵌套可变性：视图“只读”不等于元素“不可变”
即使列表本身被成功冻结，若其中存的是可变对象（如自定义类实例），外部仍可通过 ro.get(0).setName("xxx") 修改其内部状态。防范方式取决于场景：
- 元素是
String、Integer等不可变类型 → 浅拷贝 + unmodifiableList 即足够 - 元素是可变对象 → 需深拷贝（如流式映射
.map(Person::copy)）或改用不可变类型（如 record、Guava 的 ImmutablePerson） - 追求简洁安全 → 直接选用
List.of(...)（Java 9+），它不接受 null，不共享底层数组，且线程安全
