java数组通过运行时类型检查保障安全，泛型依赖编译期类型擦除和约束；因泛型类型信息在运行时不存在，故禁止创建泛型数组，避免破坏类型安全。

Java 中数组和泛型都提供类型安全，但机制完全不同：数组靠运行时检查，泛型靠编译期约束。这种分工不是设计随意，而是由 JVM 类型模型和 Java 语言演进共同决定的。

数组的运行时类型检查机制

数组是“具体化”的（reified）——它在堆中保留了元素类型的完整信息。比如 String[] 和 Integer[] 是两个不同的运行时类，JVM 能准确识别并强制校验。

• 当你把 String[] 赋给 Object[] 变量时，语法合法（因数组协变），但实际底层仍是 String[]
• 若此时向该 Object[] 写入 new Integer(1)，JVM 在赋值瞬间抛出 ArrayStoreException
• 这个检查无法绕过，也不依赖编译器；它是 JVM 字节码执行引擎的硬性规则

泛型的编译期类型保护逻辑

泛型是“非具体化”的（non-reified），其类型参数在编译后被擦除（type erasure）。ArrayList<string></string> 和 ArrayList<integer></integer> 编译成字节码后都是 ArrayList，运行时无区别。

• 类型安全全靠 javac 在编译阶段拦截非法操作，例如 list.add(123) 对 ArrayList<string></string> 直接报错
• 读取时编译器自动插入隐式转型：String s = list.get(0) 实际生成 (String) list.get(0)
• 如果擦除后类型不匹配（如误用原始类型 ArrayList），编译器只发 unchecked 警告，不再保证安全

为什么不能创建泛型数组？

因为这会同时破坏两种机制的安全前提：

• 若允许 new T[10]，JVM 需要在运行时知道 T 的确切类型来构造数组，但泛型擦除后 T 已不存在
• 若退而求其次用 new Object[10] 模拟，又失去数组的运行时类型检查能力，可能在后期写入错误类型而不报错
• 所以 Java 直接禁止 T[] arr = new T[10]，编译时报错，避免产生不可控的类型漏洞

实际开发中的应对方式

遇到需要“类型安全数组”场景时，有更稳妥的选择：

• 用 ArrayList<t></t> 或其他泛型集合替代——它们封装了类型逻辑，且规避了数组协变带来的风险
• 若必须用数组，可声明为 Object[] 并配合 @SuppressWarnings("unchecked")，但需确保内部逻辑严格控制写入类型
• 对固定类型数组，直接使用具体类型声明，如 String[]、Integer[]，享受完整的运行时检查