gradle dependencyinsight 命令可精准定位依赖来源及版本选择原因；需指定--dependency（如com.google.guava:guava）和--configuration（如runtimeclasspath），输出中标明(selected by rule)的为最终选用版本，(*)表示被仲裁排除，配合dependencies命令可高效排查冲突。
直接用 gradle dependencyInsight 命令就能查清某个依赖是从哪来的、为什么选了这个版本，特别适合排查“为什么引入了旧版 Guava？”“谁偷偷拉进了 log4j？”这类问题。
基础用法：指定依赖坐标和配置
命令格式固定，必须提供两个关键参数：
-
--dependency：填依赖的 group:artifact 或简写名称（如
guava、okhttp、com.google.guava:guava） -
--configuration：填目标依赖配置名，常见有
compileClasspath（编译期）、runtimeClasspath（运行时），Android 项目常用implementation对应的配置其实是compileClasspath
示例（查 app 模块中 guava 的来源）：
./gradlew :app:dependencyInsight --dependency com.google.guava:guava --configuration runtimeClasspath
OpenJDK 24 Windows x64
下载
OpenJDK 24 Windows x64 官方参考实现（24+36），适合 Windows 环境进行 Java 开发、编译、运行和版本兼容性验证。
快速定位冲突版本
输出里会明确标出哪个版本被最终选用（带 (selected by rule)），以及各路径引用的版本：
- 看到
\--- com.example:libA:1.0 (requires 28.0-jre)就说明 libA 是旧版 guava 的源头 - 看到
+--- com.example:libB:2.0 (requires 31.1-jre)表示它拉的是新版 - 如果某行末尾有
(*)，代表该版本存在但被仲裁规则排除了
省略配置参数的小技巧
如果项目用了 Java 或 Android 插件，Gradle 默认把 compile 配置预设为 --configuration 的默认值。但注意：compile 已废弃，实际推荐显式写 compileClasspath 或 runtimeClasspath，避免因插件版本差异导致命令失败。
配合 dependencies 命令交叉验证
先用 ./gradlew :app:dependencies --configuration runtimeClasspath 输出完整树，再用 dependencyInsight 锁定具体依赖，两者结合能更快理清依赖链路。比如在完整树里搜到多个 guava 行，就拿其中一行的精确坐标去跑 insight，结果更聚焦。
