从混乱到清晰：Maven 依赖版本管理最佳实践

在 Java 项目中，Maven 是我们最亲密的构建伙伴。但当项目规模变大、模块增多、依赖交错时，版本冲突就成了让人头疼的"隐形炸弹"。你是否也经历过这样的场景？

"为什么我明明引入了 5.0 版本，运行时却报错说找不到 4.6 的方法？"

"为什么同事拉下代码后，跑不起来？"

别急，今天我们就来聊聊 Maven 依赖仲裁机制的本质，以及如何用 dependencyManagement 实现真正的"版本统一"，告别满屏 exclusion 的混乱时代。

一、Maven 依赖仲裁：不是"谁都能上"，而是"择优录取"

首先，澄清一个误区：

✅ Maven 不会真的引入多个版本，最终只会保留一个。

那它怎么决定保留哪个？规则其实挺简单，可以用一张图概括（参考图1）：

复制代码

发现同一个依赖的多个版本
        ↓
路径深度是否相同？
   ┌────┴────┐
  不同       相同
   ↓           ↓
选路径最短的   选 pom 中先声明的
        ↓
    最终只保留一个版本

举个栗子：

你的项目 A 依赖 B (v2.0) 和 C (v3.0)
B 又依赖 D (v1.0)，C 也依赖 D (v2.0)

那么 Maven 会比较：

A → B → D：路径深度 = 2
A → C → D：路径深度 = 2

路径深度相同 → 选择在 pom 中先声明的那个版本（比如 B 先声明，则选 v1.0）

这就是为什么有时候你改了个依赖顺序，问题就"神奇地"解决了 ------ 因为仲裁规则变了！

二、曾经的"暴力解法"：到处写 exclusion

面对版本冲突，很多人的第一反应是：

❌ "到处写 exclusion，把不要的版本排除掉！"

这确实能解决问题，但代价巨大：

易漏：要改好几个地方，稍不留神就漏掉一个。
难维护：新同事不知道这段历史，可能哪天又加了个依赖，把旧版本带进来。
难看：看着就难受，到处都是 <exclusion>，代码像打了补丁。

正如图2和图3所描述的：

"能用是能用，但问题也很明显。"

"后来发现更优雅的方式。"

三、真正的"优雅之道"：父 POM + dependencyManagement

其实，Maven 早就提供了统一管理依赖版本的机制 ------ 在父 pom 的 dependencyManagement 里锁版本。

什么是 `dependencyManagement`？

它不是一个"引入依赖"的地方，而是一个"版本声明中心"。

xml 复制代码

<!-- 父 pom.xml -->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>5.3.20</version>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>2.13.3</version>
        </dependency>
    </dependencies>
</dependencyManagement>

子模块只需声明 groupId + artifactId，无需指定 version：

xml 复制代码

<!-- 子模块 pom.xml -->
<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <!-- 不写 version，自动继承父 pom 中定义的版本 -->
    </dependency>
</dependencies>

优势：

✅ 集中管理 ：所有版本在父 pom 一处定义，修改方便。

✅ 避免冲突 ：子模块不会"各自为政"，统一使用锁定版本。

✅ 清晰可读 ：没有满屏的 exclusion，代码整洁优雅。

✅ 新人友好：新同事拉下代码即可跑通，无需理解历史包袱。

四、进阶技巧：结合 properties 统一变量

为了进一步提升可维护性，建议将版本号提取为 <properties>：

xml 复制代码

<properties>
    <spring.version>5.3.20</spring.version>
    <jackson.version>2.13.3</jackson.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>${spring.version}</version>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>${jackson.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>

这样，当你需要升级 Spring 版本时，只需改一个地方 ------ spring.version。

五、总结：从"救火队员"到"架构师"

方式	优点	缺点
处处写 exclusion	快速解决当前问题	易漏、难维护、代码丑陋
dependencyManagement	集中管理、优雅统一	需要前期设计，适合多模块

🎯 真正的高手，不是靠"排除"解决问题，而是靠"设计"避免问题。

下次再遇到版本冲突，别再手忙脚乱地写 exclusion 了。回到父 pom，打开 dependencyManagement，用一行代码优雅地终结所有版本烦恼。

如果你的项目还没有父 pom，现在就是创建它的最佳时机！哪怕只有一个模块，也可以先搭好框架，为未来扩展留足空间。

从混乱到清晰：Maven 依赖版本管理最佳实践

一、Maven 依赖仲裁：不是"谁都能上"，而是"择优录取"

举个栗子：

二、曾经的"暴力解法"：到处写 exclusion

三、真正的"优雅之道"：父 POM + dependencyManagement

什么是 dependencyManagement？

子模块只需声明 groupId + artifactId，无需指定 version：

优势：

四、进阶技巧：结合 properties 统一变量

五、总结：从"救火队员"到"架构师"

什么是 `dependencyManagement`？