Java中数组拷贝与泛型擦除冲突的本质是运行时类型信息缺失与数组强类型语义的矛盾：数组依赖component type运行时校验，而泛型擦除使T退化为Object，导致无法安全验证拷贝兼容性。
Java 中数组拷贝与泛型擦除的冲突，本质是运行时类型信息缺失与数组强类型语义之间的矛盾。数组拷贝（如 System.arraycopy、Arrays.copyOf 或协变赋值）依赖组件类型的精确匹配和运行时检查；而泛型擦除让 T 在运行时退化为 Object，导致无法验证拷贝目标是否真正兼容。
数组拷贝需要确切的 component type
数组在 JVM 中是“具体化”（reified）类型，每个数组对象都记录其 component type（可通过 arr.getClass().getComponentType() 获取）。所有拷贝操作都基于该类型做校验：
-
System.arraycopy(src, 0, dst, 0, len)要求dst的 component type 是srccomponent type 的父类或相同类型，否则抛ArrayStoreException -
String[] strs = new String[5]; Object[] objs = strs;合法（协变），但objs[0] = 123运行时报错——JVM 仍按String[]的实际类型检查 - 如果允许
T[] src = ...; T[] dst = new T[10]; System.arraycopy(src, 0, dst, 0, n);，JVM 无法确认dst的 component type 是否能接受src元素，因为T已擦除
泛型擦除使拷贝上下文失去类型依据
泛型类或方法内部无法获得 T 的真实 Class 对象，也就无法构造合法的目标数组用于拷贝：
-
new T[10]编译失败：编译器禁止，因运行时无T.class -
(T[]) new Object[10]可绕过编译，但System.arraycopy(src, 0, (T[])new Object[10], 0, n)实际创建的是Object[]，component type 是Object，若src是String[]，则拷贝后丢失类型约束，后续取值可能触发ClassCastException - 泛型方法中调用
Arrays.copyOf(T[], int)会转为Object[]拷贝，返回数组的 component type 仍是Object，而非期望的T
安全绕过方式：把类型信息显式带进来
要支持类型安全的泛型数组拷贝，必须补全擦除丢失的运行时类型线索：
立即学习“Java免费学习笔记（深入）”；
- 传入
Class<T>：例如<T> T[] copyArray(T[] src, Class<T> clazz, int newSize) { return Arrays.copyOf(src, newSize, clazz); }——Arrays.copyOf的三参数重载利用clazz创建正确 component type 的新数组 - 用集合替代：
List<T>不依赖 component type，new ArrayList<>(originalList)或list.toArray(new T[0])（后者需调用方提供new String[0]等具体数组）更自然且类型安全 - 避免裸数组拷贝：在泛型容器中，优先封装为
List或自定义不可变视图，拷贝逻辑由集合自身承担（如ArrayList内部用Object[]+ 泛型契约保证）
这种冲突不是缺陷，而是 Java 类型系统一致性设计的结果：擦除保障二进制兼容，数组保留运行时类型安全，二者无法妥协共存。关键在于不试图“恢复”擦除的类型，而是主动传递所需信息。
