Arrays.asList返回的是原始数组的活视图而非副本，其内部类直接引用原数组，支持双向实时修改但不支持增删操作。
Arrays.asList 返回的是数组的“活视图”，不是副本
调用 Arrays.asList() 并不会复制数组内容，而是创建一个轻量级包装对象——java.util.Arrays.ArrayList（注意：不是 java.util.ArrayList）。这个内部类直接持有对原始数组的引用，所有读写操作都作用于同一块内存。
这意味着：
- 修改数组元素（如
arr[0] = "new"）会立即反映在 list 中 - 调用
list.set(0, "updated")也会同步改写原数组对应位置 - 两者大小始终一致，且不可增删——因为底层仍是固定长度的数组
验证联动性的典型代码片段
运行以下代码可直观看到双向实时同步：
String[] arr = {"a", "b"};
List<String> list = Arrays.asList(arr);
arr[0] = "x";
System.out.println(list); // 输出 [x, b]
list.set(1, "y");
System.out.println(Arrays.toString(arr)); // 输出 [x, y]
常见误用场景与规避方式
很多开发者误以为返回的是普通 ArrayList，从而尝试 add/remove，结果抛出 UnsupportedOperationException。根本原因在于该视图不支持结构性修改。
- 需要可变列表 → 用
new ArrayList<>(Arrays.asList(...))构造新实例 - 仅需只读遍历或查找 → 直接使用 asList()，零开销、高效
- 传入基本类型数组（如
int[]）→ 会被整体当作单个 Object 元素，导致 list.size()==1；应改用包装类型数组（Integer[]）或 Stream
为什么设计成“视图”而不是拷贝？
这是典型的性能权衡：避免无谓的内存分配和数据复制。尤其在初始化配置项、测试数据、参数校验等场景中，只需临时用 List 接口调用 contains、indexOf 等方法时，视图模式既简洁又高效。
但一旦涉及后续增删逻辑，就必须主动解耦——这不是缺陷，而是明确的设计契约。
