new T() 报错的根本原因是类型擦除，导致运行时T变为Object，JVM无法确定具体类型；需通过Class<T>参数配合反射创建实例。
为什么 new T() 直接报错：类型擦除是根本原因
Java 编译期会把所有泛型信息擦掉，T 在运行时就是 Object，JVM 根本不知道该 new 哪个具体类。所以写 new T() 会被编译器直接拒绝——不是语法限制，而是语义上无意义。
常见错误现象：Error: Cannot instantiate the type T；哪怕加了 T extends SomeClass，依然不行，因为擦除后连 SomeClass 都可能被简化为 Object。
- 泛型只在编译期做类型检查，不参与字节码生成
-
ArrayList<String>和ArrayList<Integer>运行时都是同一个ArrayList类 - 想靠
getClass()拿到泛型实际类型？不行，this.getClass().getTypeParameters()返回的是形参名（如T），不是实参
用 Class<T> 参数 + newInstance() 或 getDeclaredConstructor().newInstance()
绕过擦除的最常用办法，是把类型信息以 Class 对象显式传进来。这不是“反射黑魔法”，而是补全编译器丢掉的信息。
使用场景：写工具类、泛型 DAO、JSON 反序列化封装等需要构造实例的地方。
立即学习“Java免费学习笔记（深入）”；
- 必须传入具体类型的
Class，比如String.class，不能传T.class（这语法就不合法） -
clazz.newInstance()已废弃（Java 9+），优先用clazz.getDeclaredConstructor().newInstance() - 如果目标类构造器是 private，得先调
setAccessible(true)，否则抛IllegalAccessException - 注意
getDeclaredConstructor()不带参时，只找无参构造器；有参就老老实实传参数类型数组
示例：
public <T> T createInstance(Class<T> clazz) throws Exception {
return clazz.getDeclaredConstructor().newInstance();
}
TypeToken 能保留泛型信息，但不能直接 new 实例
Google Gson 里的 TypeToken 常被误认为能解决 new 泛型实例的问题。它确实能捕获带泛型的类型（比如 List<String>），但只是用于反序列化时的类型匹配，本身不提供构造能力。
容易踩的坑：
- 写
new TypeToken<List<String>>() {}是为了利用匿名子类的getGenericSuperclass()把泛型记下来，不是为了实例化List<String> -
TypeToken拿到的是ParameterizedType，里面只有类型描述，没有类加载器或构造逻辑 - 真要基于
TypeToken创建对象，最后还得落到某个具体的Class上，比如从ParameterizedType.getActualTypeArguments()[0]解出String.class，再用上面的方法实例化
泛型数组创建失败？new T[10] 同样被擦除，改用 Array.newInstance()
和 new T() 一样，new T[10] 编译不过，错误是 Generic array creation。原因相同：数组在运行时需要知道组件类型，而 T 已擦除。
正确做法是用反射 API 构造：
- 用
Array.newInstance(componentType, length)，其中componentType必须是运行时可得的Class - 返回的是
Object，需强制转型为泛型数组（会有 unchecked warning，但安全——只要你传的Class确实匹配） - 别用
(T[]) new Object[n]，这是典型隐患：可能在后续 add 时触发ArrayStoreException，且泛型检查完全失效
示例：
T[] arr = (T[]) Array.newInstance(clazz, 10); // clazz 是 Class<T>
真正麻烦的从来不是“怎么绕过”，而是绕过之后要不要承担类型安全责任——比如传错 Class、构造器不存在、访问权限不够，这些都得自己 try-catch，编译器不会再帮你兜底。
