arrays.aslist 的核心陷阱源于泛型擦除与数组类型交互：基本类型数组被整体视为单元素；返回的是共享数组的不可变视图；泛型推断依赖编译期静态类型，易导致 classcastexception。
Arrays.asList 看似简单，实际在泛型上下文中容易踩坑——核心问题不在方法本身，而在 Java 泛型机制与数组类型的交互规则。它不是“不好用”，而是需要理解它返回的是视图、接受的是引用、依赖的是类型擦除后的编译期推断。
基本类型数组传入会变成单元素列表
int[]、long[]、double[] 等基本类型数组传给 Arrays.asList，不会自动装箱为对应包装类型集合，而是被整体当作一个对象（即 List
- 错误写法：
int[] arr = {1, 2, 3}; List list = Arrays.asList(arr); // size == 1 - 正确做法一：改用包装类型数组，如
Integer[] arr = {1, 2, 3}; - 正确做法二：拆开传参，让编译器自动推断为
Arrays.asList(1, 2, 3)（每个 int 被视为 Integer） - 正确做法三（Java 8+）：流式装箱
Arrays.stream(arr).boxed().collect(Collectors.toList())
返回的 List 是不可变结构的视图
Arrays.asList 返回的不是 java.util.ArrayList，而是 Arrays 内部的私有类 ArrayList（继承 AbstractList），它共享原始数组引用，且不重写 add/remove/clear 等结构性方法，调用即抛 UnsupportedOperationException。
- 它支持
get、set、size、iterator等读/改操作 - 但不支持任何改变容器大小的操作：add、remove、clear、retainAll 等均不可用
- 若需可变列表，必须显式包装：
new ArrayList(Arrays.asList(...))
数组与 List 实时双向同步
因为是视图，所以数组和 List 共享同一块内存数据。修改数组元素，List.get() 立即可见；调用 List.set()，原数组对应位置也会更新。
- 例如：
String[] arr = {"a", "b"}; List<string> list = Arrays.asList(arr); arr[0] = "x";</string>→list.get(0)返回 "x" - 同理：
list.set(1, "y")→arr[1]变为 "y" - 这不是 bug，是设计特性；但若忽略这点，可能引发意料外的数据污染
泛型推断依赖参数的静态类型，而非运行时值
Arrays.asList 的签名是 <t> List<t> asList(T... a)</t></t>，这里的 T 必须在编译期确定。当传入一个已声明的变量时，推断依据是该变量的声明类型，而不是其内容。
- 比如
Object[] objArr = {"a", 1}; List<object> list = Arrays.asList(objArr);</object>—— 推断为List<object></object>还是List<object></object>？答案是后者，因为 objArr 是 Object[] 类型，而 varargs 参数匹配的是T...，此时 T = Object，所以结果是List<object></object> - 但若写成
Arrays.asList(new Object[]{"a", 1})，同样推断为List<object></object> - 真正危险的是混用：如
Arrays.asList(1, "hello", 3.14)→ T 被推断为Serializable & Comparable>（最窄公共上界），虽能编译，但后续使用易出 ClassCastException
