Java不允许new T()，根本原因是泛型类型擦除导致运行时T不存在，JVM无法确定具体类、构造器等信息；同时泛型数组也被禁止以避免协变引发的类型污染。
Java 不允许 new T()，根本原因在于泛型的类型擦除机制——T 在运行时根本不存在，JVM 字节码里没有它的痕迹，自然无法调用构造器。
类型擦除让 T 彻底“消失”
编译器会把所有泛型参数（如 T、List<string></string>）在编译阶段全部擦掉：
-
<t></t>擦除为Object（无上界时）或其上界类型（如<t extends number></t>擦除为Number） -
Box<string></string>和Box<integer></integer>编译后都是Box，getClass()返回完全相同的 Class 对象 - 用
javap -c Box.class查看字节码，找不到任何T的符号或类型信息
JVM 执行时无从下手
虚拟机运行的是字节码，而 new T() 要求它明确知道：
- T 具体对应哪个类（
String？User？还是别的？） - 该类是否有 public 无参构造函数
- 如果有多个构造器，该选哪一个
由于擦除后只剩 Object 或上界类型，这些信息全部丢失，编译器只能禁止该语法，不是疏漏，而是 JVM 层面不可行。
立即学习“Java免费学习笔记（深入）”；
额外限制：泛型数组也不行（new T[10]）
除了擦除，还叠加了数组协变问题：
- 假设允许
new T[10]，实际分配的是Object[10] - 因数组协变，它可被赋值给
Object[]引用 - 之后可能存入非 T 类型对象，取出时触发
ClassCastException - 为杜绝这种类型污染，Java 直接禁止泛型数组创建
可行的替代方式
绕过擦除限制的关键，是把类型信息从泛型系统中“拎出来”，显式传递：
-
Class + 反射：传入
Class<t></t>，调用clazz.getConstructor().newInstance() -
Supplier
：由调用方提供创建逻辑，如 () -> new UserService("prod")，零反射、高灵活性 -
工厂接口：定义
interface Instantiable<t> { T create(); }</t>，让具体类型自己实现 - 延迟初始化或默认值：对集合内部元素等场景，不强求 new T()，改用使用者传入或惰性加载
