根本原因是编译器在语法解析阶段主动拦截非具化类型数组创建，因jvm要求anewarray指令必须指向运行时真实存在的组件类型类符号，而擦除后的t或list无对应类。
Java中泛型数组创建报错“Generic array creation”，根本原因不在字节码层面，而在于编译器主动拒绝生成相关字节码——它压根不让你走到生成字节码那一步。
编译器在字节码生成前就拦截了
当你写 new T[10] 或 List<string>[] arr = new ArrayList<string>[5]</string></string>，javac 在解析语法树阶段就识别出这是“不可具化类型（non-reifiable type）的数组创建”，直接报错并终止编译。不会生成任何 class 文件，更不存在对应字节码指令（如 anewarray 的参数也无法确定）。
这是因为 JVM 要求数组必须有明确的运行时组件类型（如 java.lang.String），而擦除后的 T 或 List<string></string> 在运行时只剩原始类型（Object 或 List），无法满足 anewarray 指令对类符号常量的严格要求。
为什么 JVM 不能放宽限制？
-
数组是具化的（reified）：每个数组对象在堆中都携带其组件类型的 Class 对象（可通过
arr.getClass().getComponentType()获取），用于运行时类型检查（如ArrayStoreException） -
泛型是非具化的（non-reifiable）：
List<string></string>和List<integer></integer>编译后都是List，JVM 无法区分，也就无法为它们生成不同的数组类 - 若允许
new List<string>[10]</string>，JVM 就得凭空构造一个只接受List<string></string>实例的数组类型，但该类型在运行时并不存在——这违背类型系统一致性
对比：合法数组的字节码什么样？
比如 String[] ss = new String[3];，javac 会生成：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
iconst_3
anewarray java/lang/String
其中 anewarray 指令的操作数是常量池中指向 java/lang/String 类符号的索引——这个类在运行时真实存在、可加载、可校验。
而 new T[3] 无法提供这样一个有效类符号：因为 T 不是类名，也不是运行时可解析的类型描述符。
绕过编译检查 ≠ 绕过 JVM 限制
像 (T[]) new Object[10] 或 (List<string>[]) new ArrayList>[5]</string> 这类写法，本质是让编译器生成对原始类型数组（如 Object[] 或 ArrayList[]）的 anewarray 指令，再靠强制转型掩盖类型不匹配。JVM 执行没问题，但丢失了泛型本应提供的类型约束，可能引发堆污染。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
