java泛型擦除导致反射无法区分list与list，因运行时方法签名仅保留擦除后的原始类型（如object、list），但可通过getgenericparametertypes()获取字节码中保留的泛型声明信息。
Java 泛型擦除对反射操作的影响，核心在于：运行时方法签名已丢失泛型信息，反射只能按擦除后的原始类型匹配，无法识别 List<string></string> 和 List<integer></integer> 的区别。这不是“bug”，而是 Java 泛型的设计机制决定的。解决的关键不是消除擦除，而是绕过它的盲区、补全缺失信息、控制风险边界。
用 getGenericParameterTypes() 替代 getParameterTypes()
getMethod("xxx", String.class) 会失败，因为擦除后的方法参数是 Object 或原始类型（如 List），不是 String 或 List<string></string>。但方法签名里的泛型声明仍保留在字节码元数据中：
-
method.getParameterTypes()返回Class[]—— 全是擦除后的类型，比如Object.class、List.class -
method.getGenericParameterTypes()返回Type[]—— 可从中提取真实泛型实参，例如((ParameterizedType) type).getActualTypeArguments()得到String.class - 注意：这个信息只在方法定义处存在（如源码或 class 文件中显式声明了泛型），不依赖运行时对象实例
查找方法时用 Object.class 或原始类型作参数匹配
当目标方法来自泛型父类（如 Foo<string>.setName(T)</string>），子类继承后擦除为 setName(Object)。此时用 Bar.class.getMethod("setName", String.class) 必然抛 NoSuchMethodException：
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 正确做法是：用
Bar.class.getMethod("setName", Object.class)或Bar.class.getDeclaredMethod("setName", Object.class) - 若不确定参数类型，可遍历所有声明方法，用
method.getGenericParameterTypes()逐个比对泛型结构 - 桥接方法（bridge method）可能同时存在，需结合
method.isBridge()判断是否为编译器生成的转发方法
反射调用后避免直接强转泛型类型
反射返回值永远是 Object，而泛型擦除让 JVM 无法校验内容真实性。强转 (List<user>) method.invoke(...)</user> 看似合理，一旦实际返回的是 ArrayList<map></map>，后续取元素就爆 ClassCastException：
- 先做类型检查：
if (result instanceof List)，再逐个判断元素类型，而非依赖泛型声明 - 对集合类，用
result.getClass().getSimpleName()和element.getClass().getName()打印日志，确认真实类型流 - 反序列化场景（如 Jackson）必须传
TypeReference<list>> new TypeReference() {}</list>，否则默认解析为LinkedHashMap
需要实例化泛型对象时，显式传入 Class 对象
泛型类型擦除导致 new T() 不合法，反射也无法凭空还原 T 是什么。安全做法是把类型信息作为参数带进来：
- 构造工厂类时接收
Class<t> type</t>，调用type.getConstructor().newInstance() - 集合工具类中，若要创建带泛型语义的容器，也需传入
Class<e></e>用于运行时类型校验或序列化提示 - 不能依赖
this.getClass().getGenericSuperclass()反推泛型实参——它只对直接继承的泛型父类有效，且易受桥接和多层继承干扰
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
