核心是抓住“类从哪来、为何没加载、谁干扰了它”：优先用protectiondomain获取jar路径，失败则fallback到getresource解析；检查类加载器委托链；通过noclassdeffounderror栈顶类查依赖归属并验证runtime classpath；同名类以classpath顺序优先者为准。
在生产环境定位 Java 依赖问题，核心是抓住“类从哪来、为何没加载、谁干扰了它”这三个关键点。不靠猜，而靠运行时真实加载行为——类加载器记录、资源路径、保护域信息，都是现成的证据源。
查类实际来源：用 ProtectionDomain 和 getResource 双验证
一个类到底来自哪个 JAR？不能只信 pom.xml 或 IDE 提示，得问 JVM。
- 优先调用 clazz.getProtectionDomain().getCodeSource().getLocation()，返回 JAR 的绝对路径（如 /app/lib/commons-lang3-3.12.0.jar），适用于绝大多数 AppClassLoader 加载的类
- 若抛出 SecurityException 或返回 null（常见于动态代理类、模块化环境或受限安全策略），立即 fallback 到 clazz.getClassLoader().getResource("com/example/MyClass.class")
- 对 URL 做协议解析：若以 jar:file: 开头，提取 !/ 前的 JAR 路径；若为 file:，说明是目录结构加载（如 classes/）
看加载器层级与委托链：确认是否被父加载器“截胡”
同一个类名，不同环境加载结果不同，往往是因为类加载器委托顺序变了。
- 打印类的加载器：clazz.getClassLoader()，再逐级调用 getParent() 直到为 null（即 Bootstrap ClassLoader）
- 重点关注：该类是否本该由 Application ClassLoader 加载，却被 Extension 或 Bootstrap 加载器提前加载（例如因旧版 rt.jar 或 jre/lib/ext 中存在同名类）
- 检查 System.getProperty("java.ext.dirs") 和 "java.class.path"，确认是否有意外的 JAR 被塞进扩展路径或启动类路径
捕获 NoClassDefFoundError 的真正诱因：不止是“缺类”，更可能是“缺它的依赖”
报错类（如 okio.Options）不是你写的，而是某个 SDK 内部引用的——它缺失，往往意味着其直接依赖（如 okio-3.x.jar）根本没进 runtime classpath。
- 异常栈顶第一行就是线索，立刻去 mvnrepository.com 查这个类归属的 artifactId 和版本范围
- 用 mvn dependency:tree -Dincludes=okio（Maven）或 ./gradlew dependencies --configuration runtimeClasspath | grep okio（Gradle）确认该依赖是否出现在最终运行时依赖树中
- 若存在但版本不符，检查
是否误删，或父 POM（如 Spring Boot BOM）是否强制降级
识别静默覆盖：当两个 JAR 含同名类，谁赢了？
编译期正常、测试通过、上线报 NoSuchMethodError 或 NoSuchFieldError，大概率是高版本类被低版本 JAR 覆盖。
- 用 Maven Helper 插件（IDEA）打开 Show Dependencies 视图，红色高亮即冲突项，点开可看到所有引入路径及版本
- 手动验证：在生产机器上执行 jar -tf /app/lib/some-lib-1.2.jar | grep "SomeClass.class"，再对比同名类在另一个 JAR 中是否存在
- 关键原则：JVM 按 classpath 顺序扫描，**先出现的 JAR 中的类胜出**；fat-jar 构建时若未排序，极易埋雷
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
