在云原生和微服务架构中，系统被拆分为众多独立部署的模块。如何确保这些模块之间的版本兼容性？如何区分“正在开发中”的代码和“生产环境”的稳定代码？这一切都依赖于科学的版本管理策略。Maven 遵循严格的版本命名规范，通过版本号后缀清晰地标示软件的生命周期阶段。理解并正确使用这些版本标识，是保障团队协作顺畅、避免“依赖地狱”的关键。
Maven 版本管理的核心在于区分动态版本与静态版本。这直接决定了 Maven 仓库如何处理构件的缓存与更新。
定义：SNAPSHOT 后缀表示这是一个不稳定的、正在积极开发中的版本。它代表当前代码库的最新状态，随时可能发生变化。
命名格式：<主版本>.<次版本>.<修订版本>-SNAPSHOT
示例：1.0.0-SNAPSHOT, 2.3.1-SNAPSHOT
行为机制：
动态获取：当项目依赖一个 SNAPSHOT 版本时，Maven 默认每次构建都会检查远程仓库，看是否有比本地缓存更新的快照（基于时间戳）。如果有，会自动下载最新版本。
不可复用性：你不能依赖昨天的 1.0.0-SNAPSHOT 和今天的 1.0.0-SNAPSHOT 是完全一样的。它们的内容可能完全不同。
适用场景：
团队内部开发阶段。
持续集成（CI）流水线中的日常构建。
严禁在生产环境中使用 SNAPSHOT 依赖，因为它们的不确定性会导致生产环境构建结果不一致。
定义：不带 SNAPSHOT 后缀的版本即为发布版本。它代表一个immutable（不可变）的、稳定的状态。
命名格式：<主版本>.<次版本>.<修订版本>
示例：1.0.0, 2.1.5
行为机制：
静态缓存：一旦 Maven 下载了某个 release 版本（如 1.0.0），它会永久缓存该版本。即使远程仓库后来上传了一个新的 1.0.0（这违反了规范），Maven 默认也不会去覆盖它，除非强制更新。
一致性保证：无论何时何地构建，只要版本号相同，引用的代码内容必须完全一致。
适用场景：
对外发布的正式库。
生产环境部署。
任何需要长期稳定性和可复现性的场景。
关键原则：永远不要覆盖已发布的 Release 版本。如果需要修复 bug 或增加功能，必须升级版本号（如从
1.0.0升级到1.0.1）。
在正式发布（GA, General Availability）之前，软件通常经历多个预发布阶段。Maven 允许通过特定的后缀来标记这些阶段，帮助开发者明确版本的成熟度。
含义：软件开发的早期阶段。功能尚未完整，存在大量已知甚至未知的 Bug，架构可能仍在剧烈调整中。
用途：仅供核心开发团队或内部测试人员使用，用于验证基本功能的可行性。
命名示例：1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-alpha-20240317
稳定性：极低。API 随时可能变更，不保证向后兼容。
含义：功能已基本开发完成，进入测试阶段。主要目标是发现并修复 Bug，收集用户反馈。
用途：向更广泛的用户群体（如开源社区的早期采用者）开放测试。
命名示例：1.0.0-beta, 1.0.0-beta.2, 1.0.0-RC1 (Release Candidate，发布候选版，通常视为 Beta 的最终阶段)
稳定性：中等。API 趋于稳定，但仍可能发生破坏性变更。
含义：经过充分测试，Bug 率控制在可接受范围内，文档齐全，准备正式对外发布。
用途：生产环境部署，作为其他项目的稳定依赖。
命名示例：1.0.0, 2.3.4
稳定性：高。严格遵循语义化版本控制，补丁版本（Patch）只修复 Bug，不引入新功能或破坏性变更。
在云原生多模块项目中，遵循以下规范能极大降低维护成本：
所有子模块应继承同一个父工程版本。
在开发阶段，父工程和所有子模块通常都使用 SNAPSHOT 版本（如 1.0.0-SNAPSHOT），以便频繁迭代。
发布时，将所有模块的版本号统一升级为 Release 版本（如 1.0.0），并发布到中央仓库或私有仓库。
内部依赖：模块间相互依赖时，尽量使用 ${project.version} 引用父工程版本，确保版本同步。
外部依赖：
开发期：可以依赖第三方库的 SNAPSHOT 版本以获取最新修复（需谨慎）。
生产期：必须锁定为具体的 Release 版本，严禁使用 LATEST 或 RELEASE 这种动态标签，以免构建结果不可控。
冻结代码：停止新功能提交，仅修复严重 Bug。
版本升级：将 pom.xml 中的 -SNAPSHOT 后缀移除。
执行发布：运行 mvn clean deploy 将构件发布到 Release 仓库。
迭代开发：发布完成后，立即将版本号升级回下一个 SNAPSHOT 版本（如从 1.0.0 升级为 1.1.0-SNAPSHOT），开始新的开发周期。
