typenotpresentexception是jvm解析泛型或注解元数据时，因当前classloader无法加载签名中引用的具体类（如com.example.missingservice）而抛出的运行时异常，常见于getgenericxxx()调用、@conditionalonclass等场景，需单独try-catch并fallback到rawtype。
这个异常不是泛型“丢失”，而是 JVM 在解析泛型签名时，发现某个具体类型（比如 com.example.UserDto）在当前 ClassLoader 中根本不存在——它不关心你写的是 List<t></t> 这种变量，只会在遇到已编译进字节码的**真实类名**且该类不可见时才抛出。
为什么发生在泛型反射阶段，而不是 new 实例时
JVM 解析泛型信息（如 Method.getGenericReturnType()、Class.getGenericInterfaces()）是读取 class 文件里的 Signature 属性，属于元数据解析阶段，早于实际类加载。此时若签名里写了 java.util.List<com.example.missingservice></com.example.missingservice>，而 MissingService 不在 classpath 或被 shade 掉，JVM 就会尝试用当前 ClassLoader 加载它；失败即触发 TypeNotPresentException。这和 ClassNotFoundException 不同：后者是你主动 Class.forName() 或首次访问类静态成员时才发生。
典型触发位置与识别线索
- 堆栈里出现
sun.reflect.generics.*、SignatureParser、Reifier或AnnotationParser—— 说明卡在泛型/注解元数据解析环节 - 异常消息中明确带
Type xxx.xxx.Xxx not present，这个全限定名就是问题源头，直接全局搜索它在哪些注解值、接口继承、默认方法或泛型参数中被引用 - 常见高危点：
@ConditionalOnClass（尤其用了 class 字面量而非name字符串）、自定义注解中类型属性（@MyAnno(handler = Xxx.class)）、接口 default 方法返回泛型类型、Spring Boot Starter 的自动配置类硬编码引用
安全使用泛型反射的实践方式
- 对每个
getGenericXxx()调用单独包裹try-catch TypeNotPresentException，不要用大段逻辑共用一个 catch - 捕获后退回到原始类型：比如
method.getGenericReturnType()失败，就用method.getReturnType()替代；field.getGenericType()失败，就用field.getType() - 避免
catch Throwable：它会吞掉OutOfMemoryError等致命错误，仅捕获TypeNotPresentException及其子类即可 - 在工具类或框架层统一封装，例如提供
SafeGenericTypes.safeGetReturnType(Method)这样的辅助方法
构建与部署阶段的预防要点
- Maven Shade 插件打包时，检查是否误排除了被泛型/注解引用但未显式使用的类；可加
<keepdependencies></keepdependencies>或<relocations></relocations>显式保留 - 多模块项目中，确保下游模块删除类后，上游模块及时重新编译，否则旧 class 文件仍含已删类的泛型签名
- JDK 9+ 项目注意 JAXB、JAF 等模块化移除的 API，若代码或第三方库泛型中引用了
javax.xml.bind.JAXBContext，需补依赖或加--add-modules java.xml.bind - Spring Boot 2.4+ 可配合
@ConditionalOnClass(name = "xxx")替代@ConditionalOnClass(XXX.class)，绕过编译期 class 引用校验
