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 主动丢弃了某个版本，但该版本可能仍被其他路径加载
• 检查是否有 块意外移除了关键传递依赖（例如 Spring Boot starter 排除了 slf4j-api，导致日志框架初始化失败）

验证打包产物是否含目标类

IDE 运行正常但 java -jar 报错？大概率是 thin jar 没带依赖，或 fat jar 漏包。

Java调试

通过 JDWP 实现 Java 远程调试：连接远程 JVM、设置断点、单步执行代码、查看变量值、获取调用栈。适用于需要调试远程 Java 应用、排查运行时状态、追踪代码执行流程的场景。 术语注解 JDWP：Java Debug Wire Protocol，Java 调试有线协议（Java 远程调试底层通信协议） remote JVM：远程 Java 虚拟机 step through code：代码单步调试（步入 / 步过 / 步出调试） inspect variables：变量查看 / 变量检视 stac

下载

• 用 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 是高频“隐形雷”：编译能过，运行就炸。

• provided 表示“容器会提供”，仅适用于 Tomcat、Servlet 容器等场景；本地 mvn exec:java 或 JUnit 测试中必须改成 compile 或显式添加 runtime 依赖
• test scope 的依赖不会传递给 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 查），确认是否版本错乱

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南