Maven 依赖版本到底该怎么管理？

Maven 依赖版本管理的核心目标不是“写得越新越好”，而是让团队能稳定复现同一次构建。一个项目里常见的问题是：直接依赖写了版本，传递依赖又带来另一个版本，父 POM 或 BOM 还会覆盖一部分版本。最后代码能不能跑，往往取决于 Maven 的冲突调解规则，而不是你以为的那个版本。

推荐的版本管理方式

普通业务项目建议把版本集中放到 dependencyManagement，业务模块只声明依赖，不重复写版本。

xml
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-dependencies</artifactId>
      <version>3.3.5</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

xml
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
</dependency>

排查版本时，先看依赖树，不要靠猜：

bash
mvn dependency:tree -Dincludes=org.slf4j
mvn help:effective-pom

Maven 遇到版本冲突时通常采用“路径最近者优先”，路径一样近时再看声明顺序。这意味着传递依赖的版本可能被更近的直接依赖覆盖，也可能因为父 POM 的管理而变化。

追问

dependencyManagement 和 dependencies 有什么区别？

dependencyManagement 只负责规定版本和范围，本身不会把依赖加入项目。真正引入依赖的是 dependencies，只是它可以省略已经被管理的版本。这样做的好处是多模块项目版本统一，坏处是新同事容易误以为写进 dependencyManagement 就已经生效。边界很清楚：要用就必须在模块的 dependencies 里声明。

Maven 版本范围能不能用于生产项目？

技术上可以，比如 [1.0,2.0) 表示使用 1.x 范围内的版本。但生产项目一般不建议这么做，因为同一份代码在不同时间可能解析出不同依赖，构建不可复现。它更适合内部库探索或临时验证，不适合发布链路。真正上线时应固定版本，并把升级动作变成一次明确的代码变更。

SNAPSHOT 版本适合长期依赖吗？

不适合。SNAPSHOT 的语义是“还在变化”，远程仓库里的内容可能被重新发布，同一个版本号对应的二进制不一定相同。团队内部联调可以短期使用，但发布分支和生产构建应切到 release 版本。常见踩坑是 CI 缓存了旧 SNAPSHOT，本地又拉到了新 SNAPSHOT，问题很难复现。

BOM 和父 POM 该怎么取舍？

父 POM 能继承插件、属性、依赖管理和构建配置，适合公司内部统一工程规范。BOM 只导入依赖版本管理，不强迫项目继承某个父结构，更适合库或多技术栈项目。Spring Boot 项目如果已经继承了公司父 POM，可以用 import BOM 的方式管理 Spring 生态版本。取舍点在于你要的是“全套构建规范”，还是“只统一依赖版本”。

发现依赖冲突时怎么处理更稳？

先用 mvn dependency:tree 找到冲突来源，再决定是显式声明直接依赖、在 dependencyManagement 里统一版本，还是排除某个传递依赖。不要一上来就到处写 <exclusions>，排除太多会让依赖图变得难维护。示例：

xml
<exclusions>
  <exclusion>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
  </exclusion>
</exclusions>

版本管理做得好，升级会变成可审查、可回滚的小变更；做得差，项目会被传递依赖牵着走。Maven 的规则并不复杂，关键是把版本来源集中起来，并让每次升级都有明确理由。