Java禁止new T[10]是因为泛型类型擦除与数组协变性及运行时类型检查存在根本冲突：数组需JVM在运行时知道组件类型以执行ArrayStoreException检查，而擦除后T不存在，导致堆污染风险。

为什么Java不允许直接写 new T[10]？

这不是编译器“偷懒”，而是JVM类型模型与泛型语义之间的一次主动妥协。数组在Java中是**协变且带运行时类型信息**的——String[] 在堆上明确知道自己是 String[]，一旦往里存 Integer，运行时立刻抛 ArrayStoreException。但泛型是靠**类型擦除**实现的：List 和 List 编译后都变成原始类型 List，T 在字节码里根本不存在。如果允许 new T[10]，JVM 拿不到 T 的 Class 对象，就无法初始化数组的组件类型，更无法做后续的运行时类型检查。这种冲突不是bug，是设计使然。

类型擦除不是缺陷，而是历史选择

Java 5 引入泛型时，必须完全兼容已有的字节码和类库。为避免破坏数百万行存量代码，Sun 工程师选择了“向后兼容优先”的路径：不改 JVM，只加编译器检查。于是泛型成了“语法糖”，所有类型参数在编译后被擦除为 Object 或其上界。这就导致了一个根本矛盾：数组依赖运行时类型，泛型放弃运行时类型。两者相遇，编译器只能禁止泛型数组创建，否则就会打开堆污染（heap pollution）的闸门——比如一个本该只装 String 的 T[]，被悄悄塞进 Integer，而编译器和JVM都发现不了。

数组协变性加剧了这个矛盾

Java 数组是协变的，即 Dog[] 是 Animal[] 的子类型。这本身就有安全隐患（需要运行时检查兜底）。而泛型是**不变的**：List 不是 List 的子类型。如果强行让泛型类型（如 List）成为数组元素类型，协变规则就会和泛型的不变语义打架。例如：
– 允许 List[] arr = new List[2]；
– 又允许 arr[0] = (List) (Object[]) arr；
– 那么通过 Object[] 引用，就能往里面塞 List，彻底绕过泛型约束。
编译器封杀泛型数组，本质上是在保护你免于写出这种静默崩溃的代码。

Java Maven Secondary Analysis

分析ZIP压缩包或GitLab仓库中的Java Maven项目，确定二次开发范围、类数量、模块分布及生产相关指标。

下载

替代方案不是补丁，而是更优解

官方推荐用 ArrayList 替代 T[]，这不是退而求其次，而是契合Java集合设计哲学的选择：
– ArrayList 内部用 Object[] 存储，靠泛型擦除 + 编译期强转保障安全；
– 它天然支持类型参数，无协变风险，也不需要运行时知道 T 的具体类；
– 扩容、遍历、序列化等能力远超原生数组。
若真需数组语义（如高性能连续内存、反射操作），可用 Array.newInstance(clazz, len) 显式传入 Class，把类型信息从编译期“借”到运行时——但这要求调用方明确知道 T 的实际类型，本质上仍是把类型责任交还给开发者。

立即学习“Java免费学习笔记（深入）”；