在Maven多模块项目中，模块D无法真正“无版本号”依赖模块A、B、C；但可通过版本范围（如[1.5,)）或SNAPSHOT机制实现自动拉取最新快照版本，确保构建时使用当前工作区最新代码。
Maven 的核心设计原则之一是依赖不可变性——每个依赖必须声明明确的坐标（groupId:artifactId:version），因此严格意义上的“无版本号依赖”在标准 Maven 中不被支持。直接省略 <version> 标签会导致构建失败（Missing version 错误）。但实际开发中，我们常希望模块 D 始终基于 A/B/C 的最新开发进展进行集成测试或快速迭代。以下是两种专业、可靠且符合 Maven 最佳实践的解决方案：
✅ 方案一：使用 SNAPSHOT 版本（推荐用于多模块开发）
这是 Maven 官方为多模块协作设计的标准模式。所有子模块（A、B、C、D）应共享同一父 POM，并将版本统一声明为 1.0.0-SNAPSHOT（或类似开发版）：
<!-- 父 POM (pom.xml) --> <groupId>com.example</groupId> <artifactId>my-project</artifactId> <version>1.0.0-SNAPSHOT</version> <packaging>pom</packaging> <modules> <module>A</module> <module>B</module> <module>C</module> <module>D</module> </modules>
此时，模块 D 的依赖可写为：
<!-- D/pom.xml --> <dependency> <groupId>com.example</groupId> <artifactId>A</artifactId> <version>1.0.0-SNAPSHOT</version> <!-- 显式但动态 --> </dependency>
✅ 优势：执行 mvn clean install 时，Maven 会自动编译并安装 A/B/C 的最新 SNAPSHOT 到本地仓库，D 随即使用该版本；IDE（如 IntelliJ）也能实时感知变更。
⚠️ 注意：SNAPSHOT 依赖默认启用更新检查（updatePolicy=always），但生产环境禁止发布 SNAPSHOT 到远程仓库。
✅ 方案二：使用版本范围（仅限已发布版本，慎用）
若 A/B/C 已发布多个稳定版（如 1.2.0、1.3.0、1.4.0），可在 D 中声明版本范围：
<dependency> <groupId>com.example</groupId> <artifactId>A</artifactId> <version>[1.3.0,)</version> <!-- ≥1.3.0 的任意版本 --> </dependency>
? 支持的语法包括：
- [1.3.0,1.5.0) → 1.3.0 ≤ version < 1.5.0
- [1.3.0,) → ≥1.3.0（含所有后续主次版本）
- 1.3.+ → 过时语法，不推荐（解析行为不稳定）
⚠️ 严重警告：版本范围在构建时可能引入不确定性——Maven 会选择满足条件的最高已安装版本，而非“最新源码”。若本地仓库存在旧版（如 1.3.5），即使远程有 1.4.2，也不会自动升级，除非显式执行 mvn versions:use-latest-releases 或清理本地缓存。
❌ 不推荐方案：RELEASE 或 LATEST
虽然旧文档提及 version=LATEST 或 RELEASE，但自 Maven 3.0+ 起，该特性已被移除（见 MNG-5568）。强行使用会导致构建失败或不可预测行为，切勿在生产或 CI 环境中使用。
总结
| 场景 | 推荐方式 | 关键保障 |
|---|---|---|
| 同一代码库内多模块协同开发 | 统一 SNAPSHOT 版本 + 聚合构建 | 源码级一致性、IDE 友好、CI 可控 |
| 依赖外部已发布模块的向后兼容演进 | 语义化版本范围（如 [2.1.0,3.0.0)） | 明确兼容边界，避免意外升级 |
| 追求“永远最新”（非确定性构建） | ❌ 禁止 —— 违反可重现构建原则 | 可重现性（Reproducible Build）是 DevOps 基石 |
最终，真正的“最新代码依赖”本质是通过模块间物理耦合（聚合项目）和 SNAPSHOT 生命周期管理实现的，而非规避版本声明。遵循此原则，才能兼顾敏捷开发效率与构建可靠性。
