Maven多项目版本管理：<dependencyManagement>与<properties>该选哪一个？

在多项目（如微服务Java项目）的版本管理中，常见两种依赖版本管控方式，以下是详细对比：

一、依赖管理（Dependency Management） #

用法 #

在父pom.xml中通过<dependencyManagement>块统一定义子项目共用的依赖版本：

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-actuator</artifactId>
      <version>3.0.1</version>
    </dependency>
  </dependencies>
</dependencyManagement>

子项目的pom.xml中只需引入依赖，无需指定版本：

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
  </dependency>
</dependencies>

优缺点 #

优点

• 强版本一致性：父项目统一管控版本，子项目无法随意修改，从根源避免版本不一致问题
• 配置简洁：子项目无需重复写版本号，减少冗余配置
• 依赖传递管控：能统一管理传递性依赖的版本，避免依赖冲突

缺点

• 灵活性不足：子项目如果需要使用不同版本的依赖，必须在自身pom中显式指定版本，打破统一管控逻辑
• 配置集中：所有依赖版本都在父项目维护，当依赖数量较多时，父pom会变得臃肿

二、版本占位符（Properties 变量） #

用法 #

在父pom.xml的<properties>块中定义版本变量：

<properties>
  <driver.version>4.9.0-scylla-1</driver.version>
  <spring-boot.version>3.0.1</spring-boot.version>
  <spring-cloud.version>2022.0</spring-cloud.version>
  <lombok.version>1.18.24</lombok.version>
</properties>

子项目的pom.xml中通过变量引用版本：

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-security</artifactId>
  <version>${spring-boot.version}</version>
</dependency>

优缺点 #

优点

• 灵活性高：子项目可自行替换版本变量，单独使用不同版本的依赖；也支持通过命令行（如mvn clean install -Dspring-boot.version=3.1.0）临时指定版本构建
• 配置清晰：版本变量按类别分组，父pom的版本管理部分更易读
• 扩展性好：新增依赖时只需添加对应版本变量，无需修改大段的dependencyManagement块

缺点

• 版本一致性难保障：子项目可能随意修改版本变量，导致不同服务依赖版本不一致，增加依赖冲突风险
• 配置冗余：每个子项目的依赖都要显式写版本变量，相比第一种方式多了重复的<version>配置

三、微服务环境下的选型建议 #

如果核心诉求是严格保持依赖版本一致性，优先选择**依赖管理（Dependency Management）**方式。微服务架构中，统一的依赖版本能减少跨服务的依赖冲突，降低运维和排查问题的成本，尤其是当团队规模较大、服务数量较多时，强管控能避免人为失误导致的版本混乱。

如果团队需要一定的灵活性（比如部分服务因特殊需求要使用不同版本依赖，或需要临时测试新版本），可以选择版本占位符方式，但必须配套制定规范，限制子项目随意修改版本变量，避免一致性失控。

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