Java不允许new T()，根本原因是泛型类型擦除导致运行时T不存在，JVM无法确定具体类、构造器等信息；同时泛型数组也被禁止以避免协变引发的类型污染。

Java 不允许 new T()，根本原因在于泛型的类型擦除机制——T 在运行时根本不存在，JVM 字节码里没有它的痕迹，自然无法调用构造器。

类型擦除让 T 彻底“消失”

编译器会把所有泛型参数（如 T、List）在编译阶段全部擦掉：

• 擦除为 Object（无上界时）或其上界类型（如 擦除为 Number）
• Box 和 Box 编译后都是 Box，getClass() 返回完全相同的 Class 对象
• 用 javap -c Box.class 查看字节码，找不到任何 T 的符号或类型信息

JVM 执行时无从下手

虚拟机运行的是字节码，而 new T() 要求它明确知道：

• T 具体对应哪个类（String？User？还是别的？）
• 该类是否有 public 无参构造函数
• 如果有多个构造器，该选哪一个

由于擦除后只剩 Object 或上界类型，这些信息全部丢失，编译器只能禁止该语法，不是疏漏，而是 JVM 层面不可行。

Java Api Extractor

从 Java 项目中提取 Controller 层接口定义为 JSON 数据。

下载

额外限制：泛型数组也不行（new T[10]）

除了擦除，还叠加了数组协变问题：

• 假设允许 new T[10]，实际分配的是 Object[10]
• 因数组协变，它可被赋值给 Object[] 引用
• 之后可能存入非 T 类型对象，取出时触发 ClassCastException
• 为杜绝这种类型污染，Java 直接禁止泛型数组创建

可行的替代方式

绕过擦除限制的关键，是把类型信息从泛型系统中“拎出来”，显式传递：

• Class + 反射：传入 Class，调用 clazz.getConstructor().newInstance()
• Supplier：由调用方提供创建逻辑，如 () -> new UserService("prod")，零反射、高灵活性
• 工厂接口：定义 interface Instantiable { T create(); }，让具体类型自己实现
• 延迟初始化或默认值：对集合内部元素等场景，不强求 new T()，改用使用者传入或惰性加载

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南