Java泛型在编译期被擦除，运行时无法获取真实类型参数，导致instanceof检查泛型、获取泛型实参、创建泛型数组等操作受限，需通过TypeToken或Class参数等方式规避。
Java 的泛型在编译期被擦除，运行时无法获取真实类型参数——这是 Type Erasure 的核心表现，直接影响反射、类型判断、对象创建和集合操作等场景。
运行时类型信息丢失
泛型类型如
或
在字节码中全部退化为原始类型（
、
）。JVM 不知道泛型实参，所以：
无法通过检查泛型参数
：例如
是语法错误，编译不通过；
只能判断是否为 List，不能区分
还是
无法在运行时获取泛型实参类型
：调用
返回的是
，不是
；泛型信息已从 Class 对象中剥离
数组创建受限
：不能直接写
，因为 JVM 不支持带泛型的数组实例化（会报错），只能用
，失去类型安全性
反射中泛型信息需特殊提取
虽然运行时类对象不保留泛型，但某些结构（如字段、方法返回值、方法参数）的声明泛型仍保留在字节码的 Signature 属性中，可通过反射间接获取：
用
或
得到
子类（如
），再调用
提取实参类型
注意：仅适用于「被声明处有明确泛型」的场景，例如字段
可反射读出
；但局部变量或方法内新建的
无法追溯
常见误用：试图对
实例调用
，结果为空——因为
类本身是泛型类，但其运行时实例不携带具体参数
桥接方法与多态兼容性
为保障泛型类/接口继承关系在运行时仍满足多态规则，编译器自动生成桥接方法（bridge methods），这属于擦除带来的副作用：
例如定义
，子类
中，编译器会生成一个 public
桥接方法，调用真实的
该桥接方法在反射中可见（
），但开发者通常无需手动处理；若做 AOP 或代理，需跳过桥接方法避免重复拦截
未意识到桥接方法存在，可能误判方法重载或覆盖逻辑，尤其在基于方法签名做元编程时容易出错
实际开发中的规避策略
面对擦除限制，常用做法不是“绕过”，而是主动适配：
类型令牌（TypeToken）
：用匿名子类捕获泛型（如
），借助子类的
提取父类泛型参数，Gson、Jackson 等库内部大量使用
运行时传入
：如
，把类型信息以实参形式保留，弥补擦除损失
避免依赖泛型实参做运行时分支
：不要写
这类逻辑；改用字段标记、接口方法或配置驱动
谨慎使用泛型数组和泛型异常
：前者不可行，后者（如
）因擦除后变成
，编译器强制要求声明
，实际意义有限
泛型擦除不是缺陷，而是 Java 兼容性和实现简洁性的权衡结果。理解它如何影响运行时行为，才能写出健壮、可调试、易扩展的泛型代码。
ListMapListMapinstanceofif (obj instanceof List) obj instanceof ListListListlist.getClass()class java.util.ArrayListclass java.util.ArrayListnew ArrayList[10] new ArrayList[10]Field.getGenericType()Method.getGenericReturnType()TypeParameterizedTypegetActualTypeArguments()private List dates; Datenew ArrayList() ArrayListgetClass().getTypeParameters()ArrayListclass Box { T value; T get() { return value; } } StringBox extends BoxObject get()String get()isBridge() == truenew TypeToken>() {} getGenericSuperclass()ClassfromJson(String json, Class clazz) if (T == String.class)throws Tthrows Throwablethrows Exception