Java泛型运行时被擦除，无法动态获取实际类型；但可通过反射读取类实现接口或字段/方法声明中的泛型元数据来推导——如用GenericTypeResolver或ResolvableType解析CrudRepository中的User，或从ParameterizedType递归提取Map中的嵌套类型。
不能直接“动态获取接口的实际参数类型”，因为 Java 泛型在运行时被擦除；但可以通过 Reflect 结合**接口声明时的泛型元数据**（如实现类对泛型接口的具体化）来逆向推导出实际类型参数——关键不是“动态创建时猜”，而是“静态声明中找”。
从实现类反推接口泛型实参
这是最可靠、最常用的方式。当一个类显式实现泛型接口并具体化类型参数（如 class UserDao implements CrudRepository），JVM 会在字节码中保留该继承关系信息，GenericTypeResolver 或 ResolvableType 可据此还原。
- 用
GenericTypeResolver.resolveTypeArgument(clazz, genericIfc)直接提取第一个类型参数（如User.class） - 用
ResolvableType.forClass(clazz).getInterfaces().resolveGeneric(genericIfc)获取完整泛型结构，支持多参数、嵌套（如CrudRepository）> - 注意：仅适用于编译期已明确写出实参的场景；若写成
class UserDao implements CrudRepository（原始类型），则无法还原
通过字段或方法签名读取 ParameterizedType
当泛型出现在成员变量、方法参数或返回值声明中（如 private Map），反射可访问其 getGenericType()，再强转为 ParameterizedType 解析。
- 字段示例：
Field f = clazz.getDeclaredField("cache"); ParameterizedType pt = (ParameterizedType) f.getGenericType(); - 方法参数示例：
Method m = clazz.getMethod("process", Map.class); ParameterizedType pt = (ParameterizedType) m.getGenericParameterTypes()[0]; - 必须确保泛型是“声明在源码中”的，而非运行时构造（如
new HashMap()不保留信息） - 遇到
TypeVariable（如T）或WildcardType（如? extends Number）需额外判断边界，不能直接转Class
处理嵌套与通配符的注意事项
泛型结构越复杂，解析越依赖上下文。单纯靠 Field.getGenericType() 不足以覆盖全部情况。
-
Map需递归解析：先取> pt.getActualTypeArguments()[1]得到List，再转ParameterizedType提取User -
Collection extends Number>返回的是WildcardType，需调用getUpperBounds()获取Number.class，不能假设是具体类 -
User[]是GenericArrayType，要调用getGenericComponentType()才能得到User的泛型表示
为什么不能“动态获取”方法返回值的泛型实参？
如果一个方法声明为 TypeVariable（即 T），它没有运行时绑定信息。除非调用方传入了 TypeReference 这类显式上下文，否则无法知道 >
T 具体是什么。
- 框架如 Jackson、Spring WebMvc 要求你传
new TypeReference，本质是利用匿名子类的- >() {}
getGenericSuperclass()保留泛型信息 - 纯反射无此技巧：方法返回值的泛型参数，在调用发生前不具实参意义
