在maven多模块项目中，模块d无法真正“无版本号”依赖模块a/b/c；必须显式声明版本，但可通过版本范围（如[1.5,)）或统一父pom管理实现自动同步最新快照，确保构建一致性。
Maven 的设计原则强调可重现构建（reproducible build），因此所有依赖（包括同一项目的其他模块）都必须明确指定版本号——这是强制要求，不存在真正意义上的“无版本依赖”。然而，有几种专业、安全且常用的方式，可让模块 D 始终使用 A/B/C 的最新可用代码，同时保持构建的确定性与可维护性：
✅ 推荐方案：使用父 POM + relativePath 统一管理版本（最佳实践）
将 A、B、C、D 纳入同一个多模块聚合项目，并共用一个父 POM（例如 parent-pom），所有子模块继承其 <version>：
<!-- parent/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/pom.xml -->
<parent>
<groupId>com.example</groupId>
<artifactId>my-project</artifactId>
<version>1.0.0-SNAPSHOT</version>
<relativePath>../pom.xml</relativePath>
</parent>
<artifactId>D</artifactId>
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>A</artifactId>
<!-- 无需写版本！自动继承父POM中定义的版本 -->
</dependency>
<dependency>
<groupId>com.example</groupId>
<artifactId>B</artifactId>
</dependency>
<dependency>
<groupId>com.example</groupId>
<artifactId>C</artifactId>
</dependency>
</dependencies>✅ 优势：版本完全集中管控；mvn clean install 时 A/B/C 的最新 SNAPSHOT 会自动部署到本地仓库并被 D 解析；CI/CD 中稳定可靠。
⚠️ 不推荐方案：使用动态版本（如 RELEASE, LATEST, [1.5,)）
虽然 Maven 支持版本范围（如 [1.5,)）或特殊标记（RELEASE），官方已弃用且强烈不建议在生产项目中使用：
<!-- ❌ 反模式示例（避免使用） --> <dependency> <groupId>com.example</groupId> <artifactId>A</artifactId> <version>[1.5,)</version> <!-- 依赖解析非确定，可能跨大版本破坏兼容性 --> </dependency>
⚠️ 风险提示：
- RELEASE / LATEST 依赖远程仓库元数据，不可重现、不可缓存，破坏构建稳定性；
- 版本范围（如 [1.5,)）可能导致意外升级至不兼容版本（如从 1.9 升级到 2.0），引发编译或运行时错误；
- Maven 3.9+ 已默认禁用 RELEASE/LATEST 解析，需额外配置 --legacy-local-repository，违背现代最佳实践。
? 补充说明：跨独立仓库模块？请发布 SNAPSHOT 到私有仓库
若 A/B/C 与 D 并非同一代码库（即物理分离的独立 Maven 项目），则应：
- 将 A/B/C 的 SNAPSHOT 版本发布至公司私有仓库（如 Nexus/Artifactory）；
- 在 D 的 pom.xml 中声明具体版本（如 1.0.0-SNAPSHOT），并配置 <repositories> 指向该仓库；
- 利用 CI 流水线确保 A/B/C 提交后自动构建发布，D 再拉取——仍需显式版本，但可自动化同步。
? 总结：Maven 中没有“无版本依赖”，只有版本声明方式的差异。坚持使用统一父 POM + 继承机制，是兼顾开发敏捷性、构建可靠性与团队协作规范的唯一推荐路径。
