Kotlin构建报错debugRuntimeClasspath依赖解析失败如何解决

Caused by: org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration$ArtifactResolveException: Could not resolve all files for configuration ':app:debugRuntimeClasspath'.

上述错误是Gradle解析debugRuntimeClasspath配置下所有依赖文件失败的总提示，没有给出具体根因，按以下步骤排查定位即可解决：

• 定位具体失败依赖
  在项目根目录执行命令打印完整依赖树，直接定位拉取失败的具体依赖项：
  • macOS/Linux环境执行：./gradlew :app:dependencies --configuration debugRuntimeClasspath
  • Windows环境执行：gradlew.bat :app:dependencies --configuration debugRuntimeClasspath
    命令输出会明确标注是哪个依赖拉取失败，失败原因是网络不通、版本不存在、仓库未配置还是依赖冲突，比IDE截断的报错栈信息更完整。
• 校验仓库配置正确性
  检查Project级build.gradle中的repositories配置规则：
  • 所有Google官方依赖（AndroidX、Jetpack、AGP相关）需要配置google()仓库，且放在仓库列表的最前面
  • 托管在JitPack的第三方开源依赖，需要额外添加maven { url 'https://jitpack.io' }仓库
  • 已停止服务的jcenter()不要作为通用仓库配置，仅当个别老旧依赖必须从jcenter拉取时，通过白名单规则限定只拉取指定依赖，避免所有依赖优先走已停服的jcenter导致拉取失败
• 排查网络与缓存问题
  • 本地开启代理的场景，检查项目根目录或用户目录下gradle.properties的代理配置端口、协议是否和本地代理参数一致，配置错误会直接导致仓库连接失败
  • 国内网络环境建议配置国内Maven镜像源替代直连海外仓库，可解决绝大多数网络导致的依赖拉取失败问题
  • 执行./gradlew build --refresh-dependencies（Windows替换为gradlew.bat build --refresh-dependencies）强制刷新依赖，排除本地半拉取的损坏缓存导致的解析失败
• 校验依赖本身合法性
  • 检查Module级build.gradle中声明的所有依赖版本号是否真实存在，手滑输错版本号是非常常见的触发原因
  • 如果是依赖传递冲突导致的解析失败，通过第一步的依赖树输出找到冲突的重复依赖，使用exclude规则排除冲突的传递依赖即可
  • 注意debugRuntimeClasspath会同时包含implementation、debugImplementation、debugCompileOnly等所有debug构建变体相关的依赖，排查时不要只检查主构建的依赖配置
• 兜底处理
  以上步骤操作完仍报错的话，删除项目根目录下的.gradle文件夹、用户目录下.gradle/caches中的缓存文件，重启IDE后重新同步项目，排除IDE索引异常、本地缓存彻底损坏的问题。

内容的提问来源于stack exchange，提问作者Sparkon Vargas