gradle依赖解析失败必源于依赖坐标、仓库顺序、网络可达性或缓存状态四环节之一；应先依报错关键词区分“找不到”或“连不上”，再用--info日志逐层验证实际访问路径与响应。
Gradle依赖解析失败不是随机发生的，它一定发生在依赖坐标、仓库顺序、网络可达性、缓存状态这四个环节中的某一个。直接看报错信息本身往往误导人，真正有效的定位方式是按固定顺序验证关键节点。
看报错关键词先分清是“找不到”还是“连不上”
报错里出现 Could not resolve 或 Unable to resolve dependency，说明 Gradle 已尝试查找但没匹配到坐标——问题大概率出在仓库配置或坐标拼写；如果报错含 Connection refused、Timeout、403 Forbidden，说明请求发出去了但被拦住或超时——问题在仓库地址、镜像可用性或代理设置。
-
Could not resolve com.example:lib:2.1.0→ 检查该坐标是否真实存在、是否拼错 groupId/artifactId/version -
Could not GET 'https://jcenter.bintray.com/...'→ jcenter() 已下线，必须移除或确保它不在 repositories 列表首位 -
Connection refused: repo.maven.apache.org→ 默认 Maven Central 不可达，需切换国内镜像（如阿里云、清华）
用 --info 和 dependencyInsight 查真实解析路径
不加参数的 ./gradlew build 只显示最终失败结果，而 --info 会打印 Gradle 实际访问的每个仓库 URL 和返回状态码，这是判断“它到底去了哪、看到了什么”的唯一可靠依据。
- 运行
./gradlew app:dependencies --configuration debugCompileClasspath --info，观察日志中 “Looking in repository” 后面列出的仓库顺序和响应 - 若怀疑某个库被多个版本污染，用
./gradlew app:dependencyInsight --dependency kotlin-stdlib精准定位冲突源头 - 注意：
--info日志可能很长，重点搜Failed to list version、Resource missing、Received status code 403
检查 repositories 块的顺序和隐式注入
Gradle 按 repositories 块中声明的**从上到下顺序**查找依赖，命中即停。很多老项目明面上删了 jcenter()，却因 AGP 旧版本（如 4.1.x）、第三方插件（如 leakcanary、kotlin-kapt）或 gradle.properties 中的全局配置，悄悄把 jcenter() 插回列表最前——导致所有请求卡死在 403 上。
- 在
build.gradle（Project 级）中显式写出全部仓库，并确保mavenCentral()和google()在最前面 - 搜索整个项目：
grep -r "jcenter" . --include="*.gradle*" --include="gradle.properties"，确认无残留 - AGP ≥ 7.0 后默认不再注入
jcenter()，若仍出现，必有插件或脚本在暗中添加
别急着删缓存，先验证本地缓存是否真损坏
盲目执行 rm -rf ~/.gradle/caches 是低效操作。缓存损坏有明确信号：日志中出现 Unexpected artifact type、Corrupted metadata、或同一依赖反复下载失败且换网络也不行。
- 先试
./gradlew --refresh-dependencies强制重刷元数据，不删缓存也能绕过部分损坏 - 若仅某个依赖失败，可单独清理其缓存：
rm -rf ~/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk8/ - 删除缓存后首次构建会极慢，且无法区分是网络问题还是缓存问题——建议只在确认其他环节无误后再操作
真正卡住人的从来不是某一行报错，而是把 Could not resolve 当成终点，而不是起点。仓库顺序错一位、镜像 URL 少一个斜杠、AGP 版本带了个隐藏行为——这些细节不会自己跳出来告诉你，只能靠 --info 日志一层层剥开看它实际做了什么。
