dependencyinsight 可精准定位引入方：执行 ./gradlew :app:dependencyinsight --dependency androidx.activity:activity --configuration runtimeclasspath，输出中每条依赖链（如 +--- androidx.fragment:fragment:1.6.2 -> androidx.activity:activity:1.8.0）明确显示引入路径，末尾带 (*) 表示被仲裁丢弃，-> 后为最终生效版本。
用 dependencyInsight 精准定位引入方
Gradle 自带的 dependencyInsight 是最直接、最可靠的方式，它不依赖人工翻树，而是让 Gradle 主动告诉你：某个坐标（比如 androidx.activity:activity）被哪些路径引入、各用了什么版本、为什么最终选中了某一个。
执行命令时必须带上模块名和完整坐标：
./gradlew :app:dependencyInsight --dependency androidx.activity:activity
关键点：
- 输出中会列出所有引用该库的位置，每条都带清晰的依赖链，例如：
+--- androidx.fragment:fragment:1.6.2 -> androidx.activity:activity:1.8.0 - 如果某条路径末尾标有
(*)，说明它被仲裁规则丢弃了，不是实际生效的版本 - 若项目有多个 flavor（如
prd、dev），需指定对应 configuration，否则可能查不到：加--configuration prdRuntimeClasspath
用 dependencies 命令看全量依赖树
当 dependencyInsight 输出太简略，或你想确认整个上下文时，就得导出依赖树手动排查。直接跑会刷屏，建议定向输出到文件：
./gradlew :app:dependencies --configuration releaseRuntimeClasspath > deps.txt
然后在 deps.txt 里搜索目标坐标，比如 androidx.activity:activity。注意识别符号含义：
-
+---表示直接父依赖，往上数一层就是“谁引的” -
| \---是嵌套层级，继续往上才能找到源头 -
->后面是被强制覆盖或仲裁后的实际版本，比如androidx.activity:activity:1.7.2 -> 1.8.0 - 如果看到
androidx.appcompat:appcompat:1.6.1下挂了androidx.activity:activity:1.8.0，那答案就明确了
IDE 内快速验证但别全信
IntelliJ / Android Studio 的 External Libraries 视图能高亮显示 androidx.activity，右键 → “Jump to Source” 或 “Show Dependencies” 可以展开查看来源。但它只反映当前 resolve 结果，不展示被排除/仲裁掉的路径，容易漏掉隐藏引入源。
更稳妥的做法是结合 IDE 搜索 + 命令行交叉验证：
- 在 IDE 中按
Ctrl+Shift+Alt+N（Windows）或Cmd+Shift+O（macOS）全局搜索activity，检查build.gradle里有没有手写的implementation - 重点看所有子模块的
build.gradle和settings.gradle，有些团队会把基础依赖统一写在libs.versions.toml或自定义插件里 - 如果用了
platform或enforcedPlatform，依赖版本可能来自 BOM，这时dependencyInsight仍有效，但要留意输出里的via platform提示
为什么有时候搜不到？几个典型盲区
不是命令没用，而是你查的位置不对。常见漏点：
- 没指定模块名：
./gradlew dependencies默认查根项目，而androidx.activity往往在:app或某个 feature module 里才被拉入 - 查了 compileClasspath 却该查 runtimeClasspath：某些库只在运行时才暴露传递依赖（比如测试框架、动态插件化方案）
- 用了
api或compileOnly配置：它们不会出现在runtimeClasspath树里，得换--configuration compileClasspath - 依赖来自 buildSrc 或自定义插件：这类代码里的
implementation不会出现在主项目依赖树中，得去buildSrc/build.gradle里手动 grep
真正卡住的时候，往往不是工具不会用，而是没想清楚“它到底在哪一级参与构建”。先锁死模块、再选对 configuration、最后盯住箭头方向——比盲目重试快得多。
