getGenericType() 返回编译期保留的泛型签名元数据，如 ParameterizedType 或 TypeVariable，而非运行时真实类型；它仅对字段、方法参数、返回值及父类继承关系中声明的泛型有效，局部变量和 new 表达式中的泛型信息因擦除不可获取。
泛型擦除后，getGenericType() 返回的到底是什么
它返回的是编译期保留的**泛型签名元数据**，不是运行时真实类型。比如 Field 声明为 private List，调用 field.getGenericType() 可能拿到 ParameterizedType，其 getActualTypeArguments()[0] 是 TypeVariable（即 T），而非 String.class 或 Integer.class。这个 T 在字节码里只是个占位符，JVM 不认识它。
为什么匿名子类能“泄露”具体类型参数
因为子类在定义时固定了泛型实参，该信息会写入子类的 Signature 属性并保留在字节码中。反射通过 getClass().getGenericSuperclass() 读取这个签名，才能拿到 String 这样的实际类型。
- 必须是**直接继承或匿名实现**，如
new ArrayList；普通() {} ArrayList不行list = new ArrayList() - 只对**父类/接口声明的泛型字段或方法**有效，对局部变量、方法参数无效
- 如果父类用了通配符（如
List extends Number>），getActualTypeArguments()返回的是WildcardType，不能直接转成Class
instanceof 和 getClass() 为什么对泛型无效
这两者都依赖运行时类型信息，而泛型擦除后，List 和 List 的 getClass() 结果完全一样——都是 ArrayList.class。所以以下代码永远编译失败：
if (obj instanceof List<string>) { ... } // 编译错误：generic type not allowed in instanceof</string>
即使绕过编译（比如用反射构造对象），运行时也无从区分。这也是为什么泛型集合无法做类型精准判别，只能靠开发者约定或额外字段标记。
反射绕过检查的真实风险点在哪
风险不在于“读不到泛型”，而在于“**误以为读到了，就敢做 unsafe 操作**”。典型场景：
- 用反射调用
add()往List里塞Integer，编译器拦不住，运行时到get(0)才抛ClassCastException - 把
getGenericType()解析出的TypeVariable当成可实例化的Class，调用newInstance()失败或返回Object - 依赖泛型类型做序列化/反序列化路由，结果所有
List都走同一逻辑，数据错乱
真正安全的反射操作，必须配合显式传入的 Class 参数，而不是仅靠泛型签名推断——后者在多数生产场景下不可靠。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
