虚拟机加载错误旧类库的本质是类路径中存在同名类的多个实现，JVM按顺序“先到先得”导致误用老版本；需通过-verbose:class确认实际加载来源，用mvn dependency:tree或gradle dependencies查依赖树中的重复引入，结合jarscan扫描物理JAR冲突，并通过打印CodeSource或Spring Boot启动日志验证修复效果。
遇到虚拟机加载了错误版本的旧类库，本质是类路径中存在同名类的多个实现，JVM按顺序加载时“先到先得”，结果用了不该用的老版本。排查关键不在猜，而在确认——确认哪个类被加载、从哪来、为什么是它。
看清楚：运行时到底加载了哪个类
启动 JVM 时加上 -verbose:class 参数，能直接打印所有被加载类的来源：
- java -verbose:class -cp lib/* com.example.Main
- 运行后搜索关键词，比如 StreamBootstrapper 或你怀疑冲突的类名
- 输出类似：[Loaded com.ctc.wstx.io.StreamBootstrapper from file:/lib/woodstox-core-asl-4.1.2.jar] —— 这就锁定了实际加载的版本和路径
查源头：依赖树里找重复和隐性引入
仅看运行时加载结果还不够，要回溯到构建阶段，找出谁偷偷带进了旧版本：
- 执行 mvn dependency:tree（Maven项目）或 gradle dependencies（Gradle项目）
- 配合 grep 筛选目标库，例如：mvn dependency:tree | grep -i "woodstox"
- 重点看标红或带 omitted for conflict 的行——说明 Maven 已检测到冲突并做了仲裁，但仲裁结果未必是你想要的
- 若用 IntelliJ IDEA，装 Maven Helper 插件，在 pom.xml 里点开 “Dependency Analyzer”，冲突项会高亮显示，并列出每个版本由谁引入
挖更深：确认类是否真被重复打包进同一个 classpath
有时依赖树没报冲突，但最终 classpath 目录下却同时存在两个 JAR，比如手动拷贝或构建脚本误操作：
- 检查实际运行用的 classpath 目录（如 lib/），用命令列出来：ls -1 lib/ | grep -i woodstox
- 用工具扫描重复类：jarscan -d lib/ -class com.ctc.wstx.io.StreamBootstrapper（需提前下载 jarscan 工具）
- 输出显示多个 JAR 包含该类，就坐实了物理层面的冲突
验证与收口：改完之后别只信日志，要亲眼看见
修复后不能只看应用是否启动成功，得验证旧类确实没再加载：
- 再次加 -verbose:class 启动，确认目标类现在来自新版本 JAR
- 在代码中加一行：System.out.println(StreamBootstrapper.class.getProtectionDomain().getCodeSource());，直接打印该类所在的 JAR 路径
- 如果用 Spring Boot，启动日志里会有 Started Application in X seconds 前的类加载摘要，留意是否有 warn 提示“overriding”或“conflict resolved”
