两种方式的特点对比 #

1. 硬编码版本号（直接写死版本）

这种方式是把依赖的版本号直接写在build.gradle的依赖声明里，示例：

dependencies {
    implementation 'androidx.appcompat:appcompat:1.7.1'
    implementation 'com.google.android.material:material:1.13.0'
}

• 优势：直观性强，打开build.gradle就能直接看到当前依赖的具体版本，无需跳转其他文件；单模块小项目里配置简单，没有额外文件维护成本。
• 劣势：版本号分散在各个build.gradle文件中，升级时需要逐个修改，容易出现漏改（比如Navigation的fragment和ui组件版本需保持一致，硬编码时可能改了一个忘了另一个）；多模块项目里版本一致性难以保证，长期维护易出现版本混乱。

2. 版本目录引用（libs.xxx形式）

这种方式是把所有依赖的版本号集中放在gradle/libs.versions.toml文件中管理，build.gradle里只通过别名引用依赖，示例：

dependencies {
    implementation libs.appcompat
    implementation libs.material
}

对应的libs.versions.toml核心内容：

[versions]
appcompat = "1.7.1"
material = "1.13.0"
navigation = "2.9.7"

[libraries]
appcompat = { group = "androidx.appcompat", name = "appcompat", version.ref = "appcompat" }
material = { group = "com.google.android.material", name = "material", version.ref = "material" }
navigation-fragment = { group = "androidx.navigation", name = "navigation-fragment", version.ref = "navigation" }
navigation-ui = { group = "androidx.navigation", name = "navigation-ui", version.ref = "navigation" }

• 优势：版本集中管理，升级时只需修改libs.versions.toml里的对应版本号，就能同步更新所有引用该版本的依赖，保证相关组件版本一致；依赖声明更简洁，build.gradle文件可读性更高；支持版本范围、变量复用，非常适合多模块项目的长期维护。
• 劣势：无法在build.gradle里直接看到版本号，需要跳转到toml文件查看；刚接触的开发者需要花一点时间适应这种配置模式。

选择建议 #

• 若为小型单模块项目，两种方式均可，硬编码版本号更直接，无需额外配置；
• 若为多模块项目或需要长期维护的项目，优先选择版本目录引用的方式，这能大幅降低版本管理的复杂度，减少版本不一致带来的潜在问题；
• 从Android Studio模板的更新趋势来看，官方已在主推版本目录的依赖管理方式，这也是Gradle官方推荐的现代化方案，长期来看更利于项目的可维护性。

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