NoClassDefFoundError 表示编译时类存在但运行时无法加载，主因是类路径缺失目标类、依赖JAR未打包、模块隔离或静态初始化失败；需结合报错类名、classpath实际内容及堆栈根因（如ExceptionInInitializerError）综合排查。
直接看 NoClassDefFoundError 的报错堆栈末尾类名
这个错误不是说“完全找不到类”，而是 JVM 在初始化某个类时，发现它依赖的另一个类在运行时不可用。关键线索藏在堆栈最底下的那个类名——比如报错是 NoClassDefFoundError: org/apache/commons/lang3/StringUtils，那就说明 StringUtils 编译时有（IDE 或 javac 能过），但运行时 classpath 里没它的 .class 文件。
常见诱因包括：
- 依赖 jar 包只加在 compile scope（如 Maven 的
compile - 使用了模块化（Java 9+）但没正确声明
requires，导致类被编译进去了，却在运行时被模块系统隔离 - 类被成功加载过，但静态初始化块抛了异常（比如
ExceptionInInitializerError），之后再引用该类就会触发NoClassDefFoundError—— 此时要往上翻堆栈找真正的根因
用 jps + jstack + ClassLoader 查运行时实际加载路径
别只信 IDE 或构建脚本的 classpath 配置，得看 JVM 实际加载了什么。
先用 jps -l 找到 Java 进程 PID，再用 jstack 看线程状态（确认是否卡在类初始化）；更关键的是在代码里加一段诊断逻辑：
System.out.println("ClassLoader: " + YourClass.class.getClassLoader());
System.out.println("Class path: " + System.getProperty("java.class.path"));
注意：java.class.path 是启动时生效的，如果用了自定义 ClassLoader（如 Spring Boot 的 LaunchedURLClassLoader），还要调用其 getURLs() 方法打印真实资源路径。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
Maven 构建后检查 target/classes 和依赖 jar 是否真包含目标类
很多问题出在“以为打包了，其实没打进去”。执行 mvn clean compile package 后，立刻验证：
- 检查
target/classes/下有没有对应包路径的.class文件（比如target/classes/com/example/MyUtil.class） - 如果类来自第三方 jar，用
jar -tf target/your-app.jar | grep StringUtils确认它是否在最终 jar 的BOOT-INF/lib/（Spring Boot）或顶层目录（普通 jar）中 - 若用
maven-shade-plugin，检查是否因minimizeJar或relocation导致类被移除或改名
区分 NoClassDefFoundError 和 ClassNotFoundException
这是最容易混淆的点：ClassNotFoundException 是在显式调用 Class.forName()、ClassLoader.loadClass() 时找不到类，属于“主动加载失败”；而 NoClassDefFoundError 是被动触发的——JVM 在解析字节码、校验符号引用、或执行静态初始化时，发现某个**已编译引用但未加载成功**的类缺失。
所以当你看到 NoClassDefFoundError，不要急着去补 try-catch，优先查三点：
- 报错类名是否拼写一致（大小写、包名、是否带 $ 内部类）
- 该类是否在运行时 classpath 中真实存在（而非仅存在于编译 classpath）
- 该类的静态块是否曾抛异常（查看日志里是否有更早的
ExceptionInInitializerError）
真正难定位的往往是第三种情况：异常发生在类第一次被主动使用前的隐式初始化阶段，日志里可能只留下一个孤零零的 NoClassDefFoundError，前面的初始化失败却被吞掉了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
