typenotpresentexception 不是 classnotfoundexception，因为它是jvm解析泛型/注解等元数据时发现类型不存在而抛出的runtimeexception，发生在类加载前的字节码解析阶段，而非class.forname()失败。
为什么 TypeNotPresentException 不是 ClassNotFoundException？
因为 TypeNotPresentException 是编译期“记住了但运行时找不到”的异常，不是类加载失败本身。它常出现在泛型签名、注解值、默认方法返回类型等**元数据中引用了不存在的类**，而 JVM 在解析这些元数据时才去尝试解析类型——此时类路径已定，目标类压根没进来。
典型场景：模块升级后删了某个工具类，但老版本的注解（比如 @ApiModel(value = "OldDto")）还留在代码里；或 Spring Boot 打包时用了 spring-boot-maven-plugin 的默认配置，把某些依赖 scope 设为 provided，结果运行时缺类。
- 它继承自
RuntimeException，但根本原因在Class.forName()之前就卡在了字节码解析阶段 - 堆栈里通常带
sun.reflect.generics.parser.SignatureParser或org.springframework.core.annotation.TypeMappedAnnotations - 不能靠 catch
ClassNotFoundException来兜底——它根本不会抛那个
怎么快速定位哪个注解/泛型在作怪？
关键看异常信息里的 typeName 字段，它会明确告诉你 JVM 想找但没找到的是哪个全限定名。比如报错：TypeNotPresentException: Type com.example.dto.MissingClass not present，那就直接搜项目里所有出现 MissingClass 的地方。
重点排查位置：
立即学习“Java免费学习笔记（深入）”；
- 自定义注解的属性值（尤其是
Class类型的属性，如@MyAnno(handler = MissingClass.class)） - 接口默认方法的返回类型或参数类型（JDK 8+ 接口里写了
default List<missingclass> get()</missingclass>） - Spring 的
@ConditionalOnClass、@Import或第三方 starter 的自动配置类中硬编码的 class 引用 - Maven 多模块中，被依赖模块删了类，但当前模块的编译产物（.class）里还留着旧签名
动态加载时如何安全绕过缺失类型？
如果你控制不了注解或泛型定义（比如用的是第三方库），又必须让应用启动起来，就得在类加载前做干预。Spring Boot 2.4+ 提供了 org.springframework.boot.autoconfigure.condition.ConditionMessage 相关机制，但更通用的做法是重写 ClassLoader 的 loadClass 行为，对已知缺失类返回 byte[] 的桩类——但这太重。
更实际的解法：
- 用
-Dspring.devtools.restart.exclude=**/*.class避免 devtools 触发误加载（有时热替换会提前解析元数据） - 在
@Configuration类上加@ConditionalOnClass(name = "com.example.dto.MissingClass")把整块逻辑隔离 - 改用字符串类名 +
ClassUtils.isPresent("com.example.dto.MissingClass", getClass().getClassLoader())做运行时检查，而不是直接写死MissingClass.class - 如果只是测试环境需要，临时在
src/test/resources/META-INF/MANIFEST.MF里加DynamicImport-Package: *（OSGi 场景下）
Gradle/Maven 打包时怎么避免埋雷？
问题常出在“编译时有、运行时没有”。Maven 默认 compile scope 会进包，但如果你用了 <scope>provided</scope> 或 Gradle 的 compileOnly，又在注解里写了这个类，就会在运行时爆炸。
自查要点：
- Maven：检查
pom.xml中是否对某依赖用了provided，同时该依赖的类又被用在了@ComponentScan扫到的类的泛型/注解里 - Gradle：确认
annotationProcessor和compileOnly的边界——Lombok、MapStruct 的 processor 不该影响运行时类路径，但它们生成的代码若引用了provided类，就危险 - 启用 Maven 的
maven-enforcer-plugin，加规则banDuplicateClasses和requireJavaVersion，至少能提前暴露冲突 - CI 阶段跑
java -verbose:class -jar app.jar 2>&1 | grep MissingClass，看类到底有没有被加载
最麻烦的情况是：类在 classpath 里，但被不同 ClassLoader 加载（比如 Tomcat 的 webapp classloader 和 shared classloader 分离），导致签名解析时用错了 loader——这时候 typeName 看起来存在，实际却 not present。得查 ClassLoader.getSystemResources("com/example/dto/MissingClass.class") 返回几个路径。
