用 mvn dependency:tree 排查隐式类冲突的核心是“有策略地展开+精准过滤”：先加 -Dverbose 暴露被忽略的依赖（如“omitted for conflict”），再用 -Dincludes 锁定目标坐标查看多版本引入路径，导出文件后搜索关键词定位冲突源，并结合 -Dscope=runtime 验证运行时真实类路径。
用 mvn dependency:tree 排查隐式类冲突，核心不是“一键”，而是“有策略地展开+精准过滤”。它本身不直接标出冲突，但能暴露依赖路径差异——而类冲突往往就藏在不同版本的同一依赖被多条路径拉入时。
先看完整树，确认是否存在多版本共存
执行基础命令，观察是否有重复坐标（groupId:artifactId）对应多个 version：
mvn dependency:tree -Dverbose
-Dverbose 很关键：它会显示被忽略/仲裁掉的依赖（标为 omitted for duplicate 或 omitted for conflict），这些正是潜在冲突源。比如你看到：
- com.fasterxml.jackson.core:jackson-databind:2.15.2
- com.fasterxml.jackson.core:jackson-databind:2.13.4 （omitted for conflict）
说明项目里实际用了 2.15.2，但某模块显式声明了 2.13.4，Maven 按仲裁规则（nearest definition）丢弃了它——如果该模块内部又通过反射或 ClassLoader 强制加载旧版类，就可能触发 NoClassDefFoundError 或 LinkageError。
按具体坐标过滤，聚焦可疑依赖
不要扫全量树。用 -Dincludes 锁定目标 groupId 或 artifactId，快速定位谁引入了哪个版本：
mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
输出只保留 jackson-databind 及其所有上游路径，一目了然哪几个模块分别依赖了什么版本。再结合 -Dverbose，还能看到哪些被裁剪了。
导出树结构，用文本工具辅助分析
树太深时肉眼易漏。重定向到文件，用 grep / VS Code 搜索关键词：
mvn dependency:tree -Dverbose > deps.txt
然后搜索：
-
omitted for conflict→ 找出被覆盖的版本 -
your-bad-artifact-id→ 看所有引入路径 -
\[INFO\] +-→ 统计直接依赖层级
配合 sort | uniq -c 还能发现哪些 artifact 被重复引入最多次。
结合 -Dscope=runtime 验证运行时真实类路径
编译期 OK 不代表运行期安全。很多冲突发生在 runtime（如 Spring Boot 的 starter 自动配置、日志桥接器）。加 scope 参数看实际打包进 war/jar 的依赖：
mvn dependency:tree -Dscope=runtime -Dincludes=org.slf4j:
尤其检查 slf4j-api、slf4j-simple、logback-classic 是否混用——这是 java.lang.LinkageError: loader constraint violation 的高发区。
