Java泛型在运行时拿不到具体类型，因为类型擦除使ArrayList和ArrayList都变为ArrayList，JVM不保留泛型信息；仅通过继承带具体泛型的父类或字段声明等有限途径可获取部分类型信息。
Java泛型在运行时为什么拿不到具体类型？
因为类型擦除，ArrayList<string></string> 和 ArrayList<integer></integer> 在运行时都是 ArrayList，JVM 不保留泛型参数信息。反射调用 getClass().getTypeParameters() 或 getGenericSuperclass() 只能拿到 E 这种占位符，不是真实类型。
常见错误现象：想在方法里根据泛型参数做不同逻辑分支，比如写 if (T == String.class) —— 编译不过，运行时也无从判断。
- 只有在继承或实现带具体泛型的父类/接口时，才能通过
getGenericSuperclass()提取部分类型信息（例如class MyList extends ArrayList<string></string>） - 匿名内部类可“骗过”擦除：
new ArrayList<string>() {{}}.getClass().getGenericSuperclass()</string>能拿到ArrayList<string></string> - 字段声明中的泛型（如
private List<string> names;</string>）可通过Field.getGenericType()获取，前提是该字段在类定义中明确写出，且未被动态代理/字节码增强覆盖
如何安全地把 Object 强转为泛型 T？
不能直接写 (T) obj 并指望它校验类型——这只是告诉编译器“我信你”，实际是 unchecked cast，运行时不会抛异常，但可能后续触发 ClassCastException。
真正安全的做法是传入 Class<t></t> 实参，再调用 cast() 或 isInstance()：
立即学习“Java免费学习笔记（深入）”；
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
public <T> T safeCast(Object obj, Class<T> type) {
if (type.isInstance(obj)) {
return type.cast(obj);
}
throw new ClassCastException("Cannot cast " + obj + " to " + type.getName());
}
-
type.cast(obj)等价于(T) obj，但多了运行时类型检查 - 避免用
obj.getClass() == type，它不支持子类（比如String.class == type但 obj 是StringBuilder就失败） - 对数组、泛型集合等复合类型，
Class对象需用Array.newInstance()或Class.forName("[Ljava.lang.String;")构造，不能靠.class字面量
JSON 反序列化时怎么绕过类型擦除还原泛型？
像 gson.fromJson(json, List.class) 只能得到 ArrayList<linkedtreemap></linkedtreemap>，原始元素类型丢失。必须用 TypeToken 告诉解析器“我要的是 List<user></user>”。
关键点在于 TypeToken 利用了匿名子类的字节码保留机制：
Gson gson = new Gson();
String json = "[{\"name\":\"Alice\"}]";
List<User> users = gson.fromJson(json, new TypeToken<List<User>>() {}.getType());
- 不要写
new TypeToken<list>>().getType()</list>—— 没有匿名子类，getType()返回的是java.lang.reflect.TypeVariable，Gson 无法解析 - Jackson 用
new TypeReference<list>>() {}</list>同理，原理一致 - 若泛型嵌套较深（如
Map<string list>>></string>），手写TypeToken易错，建议提取为常量或封装工具方法
类型转换和类型擦除共同导致的典型坑
最隐蔽的问题出现在泛型方法 + 重载 + 自动装箱组合场景下：
void handle(List<String> list) { System.out.println("string list"); }
void handle(List<Integer> list) { System.out.println("int list"); }
List<String> s = Arrays.asList("a");
handle(s); // OK，输出 "string list"
List<Object> o = Arrays.asList("a", 1);
handle(o); // 编译错误：ambiguous
原因：擦除后两个 handle 方法签名都变成 handle(List)，JVM 无法区分；而编译器又无法根据泛型实参推导唯一重载版本。
- 避免对泛型参数做方法重载，改用不同方法名（
handleStringList/handleIntegerList）或统一接收Collection>+ 运行时instanceof分支 -
Arrays.asList()返回的是不可变ArrayList子类，其set()抛UnsupportedOperationException，和类型擦除无关但常被误认为转型失败 - Lombok 的
@Data会为泛型字段生成toString()，但擦除后打印出的是field=ArrayList@xxx，看不出元素类型——这不是 bug，是设计使然
类型擦除不是缺陷，是 Java 兼容性和 JVM 简洁性的权衡结果；所有绕过它的技巧，本质都是用额外元数据（Class 对象、TypeToken、字段签名）把本该编译期解决的事拖到运行时补救。越想“自动”还原泛型，越要小心多一层反射或字符串解析带来的开销和不确定性。
