泛型擦除排查核心是确认字节码是否保留泛型签名，需用javap -s验证；桥接方法要过滤isbridge()；type子类型须instanceof判断后递归解析；字段与方法参数泛型稳定性不同；局部变量泛型运行时不可见；解析后需校验实例兼容性。
排查泛型擦除导致的 getGenericParameterTypes 解析偏差，核心在于确认「泛型信息是否真实存在于字节码签名中」，而非假设它一定可读。嵌套结构（如 Map<string list>></string>）容易出错，不是因为反射能力不足，而是解析路径没走对或类型判断不完整。
检查方法签名是否保留了完整泛型信息
很多偏差源于目标方法本身在编译后就没带泛型签名 —— 比如参数用了原始类型、被桥接方法覆盖、或来自 lambda/匿名内部类。
- 用
javap -s ClassName查看字节码签名：若方法参数显示为Ljava/util/Map;（无泛型），说明编译时已擦除，getGenericParameterTypes()返回的必然是Class类型，不是ParameterizedType - 若签名显示为
Ljava/util/Map<ljava>>;</ljava>，才说明泛型信息完整保留，可继续解析 - 继承重写场景下，子类方法可能触发桥接方法（bridge method），此时
getDeclaredMethods()可能返回多个同名方法，需过滤掉isBridge() == true的干扰项
逐层判断 Type 子类型，避免强转失败
嵌套泛型中，getActualTypeArguments() 返回的每个元素可能是多种 Type 子接口，不能默认当作 Class 或直接强转为 ParameterizedType。
- 先用
instanceof明确判断：是Class、ParameterizedType、WildcardType、TypeVariable还是GenericArrayType - 对
ParameterizedType，必须递归调用其getActualTypeArguments()，例如解析List<map integer>></map>时，第一层取到Map<string integer></string>，第二层再拆解String和Integer - 遇到
TypeVariable（如<t> void f(T t)</t>中的T），单独无法确定具体类型，需结合方法所在类的泛型声明（Method.getDeclaringClass().getTypeParameters()）或调用上下文推断
字段与方法入口要区分使用场景
同一泛型结构，在字段声明和方法参数中，反射行为稳定性不同。
- 字段泛型（如
private Map<string list>> config;</string>）通过Field.getGenericType()获取，相对稳定，但要注意字段必须是类直接声明的，继承来的字段可能因访问权限或编译优化丢失签名 - 方法参数泛型更可靠，尤其当方法定义在接口或泛型类中时（如
interface Dao<t> { List<t> findAll(); }</t></t>），JVM 会强制保留签名，适合框架统一提取实体类型 - 局部变量、
new表达式、方法体内声明的泛型集合，运行时完全不可见，反射无法获取任何泛型信息，这类场景必须靠外部传入TypeToken或约定类型规则
验证解析结果是否匹配实际运行对象
即使解析出 Integer.class，也不能保证注入对象就安全 —— 还需校验实例是否真正兼容。
- 对集合元素类型（如
List<user></user>的泛型实参User.class），可用obj.getClass().isAssignableFrom(expectedType)做前置检查 - 避免用
instanceof判断泛型类型（如list instanceof List<string></string>），这在运行时语法非法且无意义 - 调试时打印完整
Type.toString()，比只看Class.getSimpleName()更能暴露嵌套层级和通配符细节（如? extends Number会显示上界）
