arrays.aslist返回的list虽实现collection接口但不可修改，add/remove等操作抛unsupportedoperationexception；基本类型数组会整体作为单元素，需用包装类或流转换。
Arrays.asList 返回的 List 看似是 Collection 接口的实现，但实际使用中常因“假兼容”踩坑——它实现了 Collection 接口，却拒绝大部分修改操作。
它确实 implements Collection，但只支持部分方法
Arrays.asList() 返回的是 Arrays.ArrayList（Arrays 的私有静态内部类），它继承 AbstractList，实现了 Collection 接口声明的所有方法签名，但关键行为受限：
- 允许调用：get、set、size、contains、indexOf、iterator、forEach、spliterator 等读取和遍历方法
-
禁止调用：add、remove、clear、addAll、removeAll、retainAll —— 这些方法直接继承 AbstractList 中的默认实现，统一抛出
UnsupportedOperationException - 底层数组不可扩容，结构性修改无意义，所以设计上就禁用
与真实 ArrayList 的兼容性差异
虽然两者都实现 List 和 Collection 接口，但行为契约不同：
- 传入
new ArrayList()的地方，能安全调用 add()；传入Arrays.asList(...)就可能在运行时崩溃 - 某些框架（如 MyBatis 批量插入、Spring Data JPA saveAll）接受 Collection 参数，若传入 Arrays.asList 结果，只要不触发修改逻辑就可正常工作；但若框架内部尝试 clear() 或 add()，就会失败
- 泛型擦除后，编译器无法区分二者，只能靠文档或运行时异常暴露问题
安全适配 Collection 接口的常用写法
若需一个真正可修改、完全兼容 Collection 接口的实例，应显式包装：
- 转为可变 ArrayList：
new ArrayList(Arrays.asList("a", "b", "c")) - 转为可变 LinkedList：
new LinkedList(Arrays.asList(1, 2, 3)) - 避免误用 asList 后直接传给需要 add/remove 的 API，比如：
❌someService.process(Arrays.asList(items));（不确定 process 是否修改）
✅someService.process(new ArrayList(Arrays.asList(items)));
基本类型数组的陷阱：不是类型不匹配，而是语义错位
传 int[] 给 Arrays.asList 不会编译报错，但结果完全不符合直觉：
-
int[] arr = {1, 2, 3}; List list = Arrays.asList(arr);→ list.size() == 1，元素是整个 int[] 数组对象 - 这是因为泛型擦除 + 基本类型不能作为泛型参数，导致编译器把 int[] 当作一个 Object，而非拆成三个 Integer
- 正确做法：用包装类型数组
Integer[] arr = {1, 2, 3};，或流式转换Arrays.stream(arr).boxed().collect(Collectors.toList())
