Java数组通过运行时类型检查保障安全，泛型依赖编译期类型擦除和约束；因泛型类型信息在运行时不存在，故禁止创建泛型数组，避免破坏类型安全。
Java 中数组和泛型都提供类型安全，但机制完全不同：数组靠运行时检查，泛型靠编译期约束。这种分工不是设计随意，而是由 JVM 类型模型和 Java 语言演进共同决定的。
数组的运行时类型检查机制
数组是“具体化”的（reified）——它在堆中保留了元素类型的完整信息。比如 String[] 和 Integer[] 是两个不同的运行时类，JVM 能准确识别并强制校验。
- 当你把
String[]赋给Object[]变量时，语法合法（因数组协变），但实际底层仍是String[] - 若此时向该
Object[]写入new Integer(1)，JVM 在赋值瞬间抛出ArrayStoreException - 这个检查无法绕过，也不依赖编译器；它是 JVM 字节码执行引擎的硬性规则
泛型的编译期类型保护逻辑
泛型是“非具体化”的（non-reified），其类型参数在编译后被擦除（type erasure）。ArrayList<String> 和 ArrayList<Integer> 编译成字节码后都是 ArrayList，运行时无区别。
- 类型安全全靠
javac在编译阶段拦截非法操作，例如list.add(123)对ArrayList<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>或其他泛型集合替代——它们封装了类型逻辑，且规避了数组协变带来的风险 - 若必须用数组，可声明为
Object[]并配合@SuppressWarnings("unchecked")，但需确保内部逻辑严格控制写入类型 - 对固定类型数组，直接使用具体类型声明，如
String[]、Integer[]，享受完整的运行时检查
