typenotpresentexception 在泛型反射时发生，因jvm解析泛型签名时遇到当前classloader无法加载的类；常见于shade/fatjar场景，需对getgenericxxx()单独try-catch并fallback到非generic方法。
为什么 TypeNotPresentException 总在泛型反射时冒出来
它不是编译失败，也不是类找不到，而是 JVM 在解析泛型签名（比如 Class.getGenericInterfaces()、Method.getGenericParameterTypes()）时，发现某个类型变量实际引用了一个**已编译但当前 ClassLoader 无法加载的类**——典型如模块未引入、依赖被 shade 掉、或测试 classpath 和运行 classpath 不一致。
常见错误现象：TypeNotPresentException 堆栈里往往看不到你写的代码，而是在 sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.toString() 或类似位置抛出；用 getDeclaredMethods() 拿到方法后一调 getGenericReturnType() 就崩。
- 不是所有泛型都会触发：只有当泛型类型参数指向一个真实类（而非
T、E这种未绑定的类型变量），且该类在当前上下文不可见时才发生 - 和
NoClassDefFoundError不同：后者是运行时主动 new/调用，前者是 JVM 解析泛型元数据时被动尝试加载 - 容易被误判为“类不存在”，其实类文件可能就在 jar 里，只是没进当前
ClassLoader
getGenericXxx() 调用前怎么安全兜底
别等它炸，主动检查。JVM 不提供“泛型类型是否可解析”的 API，但你可以捕获并忽略 —— 只要你的逻辑不强依赖那个泛型的具体类型，就别让异常穿透。
使用场景：写通用序列化工具、AOP 参数提取、DTO 自动映射等需要遍历泛型结构的代码。
立即学习“Java免费学习笔记（深入）”；
- 对每个
getGenericXxx()调用单独 try-catchTypeNotPresentException，不要包一大段逻辑 - 捕获后返回
Object.class或rawType（比如method.getReturnType()）作为 fallback，避免空指针或中断流程 - 不要 catch
Throwable：它可能掩盖真正的StackOverflowError或OutOfMemoryError
示例：
try {
Type genericType = method.getGenericReturnType();
// 处理泛型返回值
} catch (TypeNotPresentException e) {
// 退回到原始类型
Class<?> rawType = method.getReturnType();
}
Maven Shade / Spring Boot Fat Jar 下为什么特别容易中招
Shade 插件默认会重命名（relocate）包，但不会改 class 文件里的泛型签名字节码 —— 签名里还存着老包名，而新类只在新包路径下存在，导致 JVM 解析签名时按旧名去查，自然找不到。
Spring Boot 的 spring-boot-maven-plugin 打 fat jar 时若依赖有冲突或排除不当，也会让某些泛型引用的类被剔除出最终 jar，但签名残留。
- 检查
target/classes/META-INF/MANIFEST.MF里Class-Path是否漏了关键依赖 - 用
javap -v YourClass | grep Signature查看泛型签名字符串，确认里面引用的类名是否和实际类路径一致 - Shade 插件加
<shadedartifactattached>true</shadedartifactattached>后对比 original vs shaded jar 的Signature属性差异
泛型擦除后还能不能绕过这个异常
不能靠擦除“躲开”，因为 TypeNotPresentException 发生在泛型信息解析阶段，早于类型擦除执行时机。擦除影响的是运行时类型，而这个异常卡在“读取泛型定义”这一步。
真正有效的绕过方式只有两个：要么确保所有泛型引用的类都在 classpath 里（最正统），要么放弃读取泛型信息，只用 getXXX() 系列非 generic 方法（比如用 method.getReturnType() 代替 getGenericReturnType()）。
- 如果你只关心字段/方法的原始类型，一律用
getReturnType()、getParameterTypes()、getGenericInterfaces()改成getInterfaces() - 想保留泛型能力？那就得接受必须处理
TypeNotPresentException—— 它不是 bug，是 JVM 对缺失类型的明确拒绝 - 注意：
instanceof、Class.isAssignableFrom()这些运行时操作完全不受影响，它们不碰泛型签名
复杂点在于，同一个泛型结构里可能混着可解析和不可解析的类型；容易被忽略的是，连 toString() 都可能触发解析 —— 比如把 ParameterizedType 直接打日志。
