不能直接写 new T()，因为泛型在运行时被类型擦除，JVM 字节码中不存在 T 的具体信息，无法确定构造方法；可靠替代方案包括反射、Supplier 和工厂类。
不能直接写 new T()，根本不是语法疏忽，而是 JVM 字节码层面的设计决定——泛型类型在运行时根本不存在。
类型擦除是核心原因
Java 编译器会把所有泛型参数（如 T、List<string></string>）在编译后全部擦除，替换成原始类型（通常是 Object 或上界类型）。比如：
-
public class Box<t> { T value; }</t>编译后，T全变成Object -
javap -c Box.class查看字节码，找不到任何T的痕迹 - 运行时
Box<string></string>和Box<integer></integer>的getClass()完全相同
new T() 在字节码里无从下手
JVM 执行的是字节码，它需要明确知道调用哪个类的哪个构造方法。而 T 擦除后只剩 Object，虚拟机无法回答这些问题：
- 这个
T到底对应哪个具体类？ - 该类是否有 public 无参构造函数？
- 如果有多个构造函数，该选哪一个？
所以编译器直接禁止 new T()：不是不想支持，是运行时根本没条件支持。
三种可靠替代方案（附可运行代码）
绕过擦除限制的关键，是把“类型信息”从泛型系统中剥离出来，交由显式传入的 Class<T> 或函数式接口承载：
-
反射方式（最常用）：要求类型有 public 无参构造
public <T> T create(Class<T> clazz) throws Exception {<br> return clazz.getDeclaredConstructor().newInstance();<br>} -
Supplier 接口方式（推荐）：完全解耦，不依赖构造函数可见性
public <T> T create(Supplier<T> supplier) {<br> return supplier.get();<br>}<br>// 调用：create(() -> new UserServiceImpl()) -
工厂类方式（适合复杂初始化）：把创建逻辑封装进实现类
interface Creator<T> { T create(); }<br>public <T> T create(Creator<T> creator) { return creator.create(); }
避坑提醒：别踩这些常见雷区
很多方案看似能跑通，实际隐藏运行时风险：
-
Class.newInstance()已被废弃，且对 private 构造函数或无参构造缺失（如Integer）直接抛NoSuchMethodException - 仅靠泛型声明（如
<T extends SomeInterface>）不能保证可实例化，仍需额外提供创建能力 - 用
new Object()强转成T是类型不安全的，编译器会警告 unchecked cast，运行时可能出错
