最常用方式是在模块级build.gradle的dependencies块中用implementation等配置项声明依赖，坐标格式为'group:name:version'，版本须写死；Android项目禁用已废弃的compile，测试用testImplementation；推荐通过libs.versions.toml集中管理版本。
直接在 build.gradle 里用 dependencies 块声明
这是最常用、最直白的方式，适用于绝大多数场景。Gradle 的 dependencies 块本质是调用 Project#dependencies 方法，传入一个闭包来配置依赖项。
关键点不是“怎么写”，而是“写在哪”和“用哪个配置项”：
-
build.gradle（模块级）里写，不是根项目的build.gradle；Android 项目中尤其注意：必须在app/build.gradle或对应 module 的build.gradle中 - 优先用
implementation，不用已废弃的compile；测试依赖用testImplementation，Android Instrumented 测试用androidTestImplementation - 坐标格式统一为
'group:name:version'，比如implementation 'androidx.core:core-ktx:1.12.0' - 版本号务必写死，避免
'1.+'或'2.x'—— 否则 CI 构建可能因远端仓库更新而行为突变
通过版本目录（libs.versions.toml）集中管理
Android Studio 新项目默认启用该方式，本质是把版本号和坐标解耦，提升可维护性。它不改变依赖逻辑，只改变声明位置。
操作路径很明确：
- 编辑
gradle/libs.versions.toml，在[versions]下定义别名：agp = "8.4.0" - 在
[libraries]下绑定坐标：core-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "ktx-version" } - 回到
build.gradle，用implementation libs.core.ktx引用（注意是点号分隔，不是冒号） - IDEA/AS 会自动识别
libs.versions.toml，提供补全和跳转；但若手动改错格式（如漏掉引号、多加空格），会导致整个依赖块失效且报错不直观
插件本身添加依赖？别被名字带偏
“Gradle 插件添加依赖”这个说法容易误解。插件（如 com.android.application）本身不负责往你的项目加业务依赖，它只提供构建能力（编译、打包、签名等）。真正加依赖的是你写的 dependencies 块。
但有两类例外需留意：
- 某些第三方插件（如
org.jetbrains.kotlin.jvm）会在应用时自动引入 Kotlin 标准库——这是插件内部的dependencies，你无需重复声明，否则可能触发版本冲突 - 自定义插件可通过
project.dependencies.add("implementation", ...)动态注入依赖，但普通项目极少需要；一旦用了，就绕过了build.gradle的可读性，调试困难，CI 环境也容易因插件加载顺序出问题
常见报错和绕不开的坑
依赖加了却编译失败？大概率卡在这几个地方：
-
Could not resolve all files for configuration ':app:debugRuntimeClasspath'：典型是仓库没配对，比如用了jcenter()（已停服），但没补mavenCentral()或google() - 类找不到，但
implementation明明写了：检查是否误用了compileOnly或api（后者只对子模块透出，当前模块不可见） - IDEA 显示红色但命令行
./gradlew build成功：IDE 缓存未刷新，执行File → Reload project，别信 “Sync Now” 小弹窗 - 依赖传递进来了不该有的东西（比如 Log4j 2.17.2 被某个库偷偷带进来）：用
./gradlew app:dependencies --configuration runtimeClasspath查树，再用exclude group: 'org.apache.logging.log4j'排除
最麻烦的其实是“看起来加对了，但运行时崩溃”——这往往意味着依赖范围（scope）或 classpath 加载顺序出了问题，而不是语法错误。这时候得看实际堆栈里的类加载器链，而不是盯着 build.gradle 反复检查。
