Java类加载失败核心是确认目标类在运行时真实、可访问、被正确加载，需通过mvn dependency:tree -Dverbose查依赖是否被排除或冲突丢弃，jar -tf验证fat jar是否含该类，严格核对scope（如provided/test在本地无效），并用jcmd/jmap定位线上实际加载的类及版本。
Java 类加载失败引发的线上故障，核心在于确认“目标类在运行时是否真实、可访问、被正确加载”，而不是只看编译或本地运行是否通过。这类问题往往本地无异常、上线即报错，排查需聚焦运行时真实环境。
确认类是否真在运行时 classpath 中
很多故障源于 pom.xml 写了依赖，但实际没进 classpath——可能被冲突排除、scope 误配、或打包遗漏。
- 执行 mvn dependency:tree -Dverbose，搜索报错类的全限定名（如
com.fasterxml.jackson.databind.ObjectMapper），看它来自哪个 artifact；搜不到说明该 jar 根本未参与构建 - 留意输出中是否有 omitted for conflict 或 omitted for duplicate ——这是 Maven 主动丢弃了某个版本，但该版本可能仍被其他路径加载
- 检查是否有
<exclusions></exclusions>块意外移除了关键传递依赖（例如 Spring Boot starter 排除了 slf4j-api，导致日志框架初始化失败）
验证打包产物是否含目标类
IDE 运行正常但 java -jar 报错？大概率是 thin jar 没带依赖，或 fat jar 漏包。
- 用 jar -tf your-app.jar | grep ObjectMapper（Linux/mac）或 jar -tf your-app.jar \| findstr ObjectMapper（Windows）直接检查 jar 包里是否存在对应 .class 文件
- Maven 项目需确认是否用了
maven-shade-plugin或spring-boot-maven-plugin；默认mvn package生成的是 thin jar，不包含依赖 - Spring Boot 项目若执行
mvn install而非mvn spring-boot:repackage，生成的 jar 无法直接运行
检查 scope 是否匹配运行环境
provided 和 test 是高频“隐形雷”：编译能过，运行就炸。
立即学习“Java免费学习笔记（深入）”；
-
<scope>provided</scope>表示“容器会提供”，仅适用于 Tomcat、Servlet 容器等场景；本地mvn exec:java或 JUnit 测试中必须改成compile或显式添加 runtime 依赖 -
testscope 的依赖不会传递给 main 模块；如果测试代码和主流程都用到了某工具类（如 AssertJ），就得在主模块里单独声明 - Android 项目中，
androidx.*或com.google.android.material类在纯 Java 模块里不可见，需确认模块类型和targetSdk配置
定位 JVM 实际加载的类来源
运行时真正起作用的 classpath，可能和你想象的不一样。不能只看配置，要看 JVM 加载了什么。
- 在线上出问题的机器上，用 jcmd
VM.class_hierarchy | grep -i "ClassName" （Java 14+）查类加载器层级 - 用 jmap -clstats
查类加载器分布，再结合 find /path/to/app -name "*jackson*" 扫描所有疑似 JAR - 对每个匹配 JAR 执行 jar -tvf xxx.jar | grep ObjectMapper，比对 Class-Path 和实际 class 文件的
MajorVersion（可用javap -verbose查），确认是否版本错乱
