为何使用版本变量$version而非固定版本号如'2.7.0'？

一、为什么要使用版本变量（如$retrofit_version）而非固定版本号？ #

直接写死固定版本号看似简单，但在项目迭代和维护中会带来诸多问题，版本变量的优势主要体现在这几点：

• 统一管控，减少重复劳动：同一系列的依赖（比如Retrofit核心库和它的转换器）通常需要保持版本一致，用变量定义后，升级时只需要修改一处，不用逐个查找依赖项修改版本号。
• 避免版本不兼容风险：手动写固定版本号时，很容易出现“Retrofit用2.9.0但转换器用2.8.0”这类失误，引发兼容性bug；版本变量能从根源保证同组依赖版本统一。
• 提升配置可读性：依赖列表里不用重复堆砌版本号，一眼就能分辨哪些依赖属于同一版本组，配置结构更清晰。
• 多模块项目友好：在多模块项目中，版本变量可以定义在根目录的配置文件里，所有子模块共用，确保全项目依赖版本一致，不会出现模块间版本冲突。

二、依赖配置中不直接写版本号的常见实践方式 #

除了用简单的变量定义，还有几种更规范的实践：

• 项目级ext变量：在根项目的build.gradle中通过ext块定义全局版本变量：

  ext {
      retrofit_version = "2.9.0"
      okhttp_version = "4.9.0"
  }
  

  子模块直接引用$retrofit_version即可。
• Gradle版本目录（Version Catalog）：这是Gradle 7.0+推荐的方式，在settings.gradle中引入libs.versions.toml文件，集中管理所有依赖版本：

  # libs.versions.toml
  [versions]
  retrofit = "2.9.0"
  okhttp = "4.9.0"
  
  [libraries]
  retrofit-core = { group = "com.squareup.retrofit2", name = "retrofit", version.ref = "retrofit" }
  retrofit-moshi = { group = "com.squareup.retrofit2", name = "converter-moshi", version.ref = "retrofit" }
  okhttp = { group = "com.squareup.okhttp3", name = "okhttp", version.ref = "okhttp" }
  

  然后在依赖中引用：

  dependencies {
      implementation libs.retrofit.core
      implementation libs.retrofit.moshi
      implementation libs.okhttp
  }
  

• 依赖平台（BOM）：对于像Square、Google这类有统一版本管控的依赖组，可以直接引入对应的BOM，依赖自动对齐版本：

  dependencies {
      // 引入OkHttp BOM
      implementation platform("com.squareup.okhttp3:okhttp-bom:4.9.0")
      // 依赖无需写版本号
      implementation "com.squareup.okhttp3:okhttp"
      implementation "com.squareup.okhttp3:logging-interceptor"
  }
  

三、两种Gradle写法的选择：优先第一种（版本变量写法） #

对比你给出的两种写法，第一种写法（使用版本变量）是绝对更优的选择，原因如下：

1. 维护效率碾压：比如要把Retrofit升级到2.10.0，第一种写法只需要修改retrofit_version变量，第二种写法则要手动修改两个依赖项，依赖越多，这种差异越明显。
2. 从根源避免人为失误：第二种写法中，如果不小心把converter-moshi的版本写成2.8.0，就会出现版本不兼容问题；第一种写法用同一个变量，完全杜绝这种错误。
3. 配置更整洁易读：依赖列表没有冗余的版本号，结构清晰，尤其是项目依赖较多时，优势非常明显。

而第二种写法（固定版本号）只适合临时测试或极小的Demo项目，在正式项目中会给后续维护埋下大量隐患。

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