在maven多模块项目中，模块d无法真正“无版本号”依赖模块a/b/c；必须显式声明版本，但可通过版本范围（如[1.5,)）或统一父pom管理实现自动同步最新快照，确保构建一致性。
Maven 的设计原则强调可重现构建（reproducible build），因此所有依赖（包括同一项目的其他模块）都必须明确指定版本号——这是强制要求，不存在真正意义上的“无版本依赖”。然而，有几种专业、安全且常用的方式，可让模块 D 始终使用 A/B/C 的最新可用代码，同时保持构建的确定性与可维护性：
✅ 推荐方案：使用父 POM + relativePath 统一管理版本（最佳实践）
将 A、B、C、D 纳入同一个多模块聚合项目，并共用一个父 POM（例如 parent-pom），所有子模块继承其
com.example my-project 1.0.0-SNAPSHOT pom A B C D
com.example my-project 1.0.0-SNAPSHOT ../pom.xml D com.example A com.example B com.example C
✅ 优势：版本完全集中管控；mvn clean install 时 A/B/C 的最新 SNAPSHOT 会自动部署到本地仓库并被 D 解析；CI/CD 中稳定可靠。
⚠️ 不推荐方案：使用动态版本（如 RELEASE, LATEST, [1.5,)）
虽然 Maven 支持版本范围（如 [1.5,)）或特殊标记（RELEASE），官方已弃用且强烈不建议在生产项目中使用：
com.example A [1.5,)
⚠️ 风险提示：
- 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），并配置
指向该仓库； - 利用 CI 流水线确保 A/B/C 提交后自动构建发布，D 再拉取——仍需显式版本，但可自动化同步。
? 总结：Maven 中没有“无版本依赖”，只有版本声明方式的差异。坚持使用统一父 POM + 继承机制，是兼顾开发敏捷性、构建可靠性与团队协作规范的唯一推荐路径。
