总结：生产环境release、snapshot两种包版本该如何管理与发布构建
- 一·Release、Snapshot两种包该如何分别管理与发布构建呢？
-
- [1. 核心开关：版本号命名](#1. 核心开关：版本号命名)
- [2. 如何发布构建 (Deploy)](#2. 如何发布构建 (Deploy))
- [3. 如何管理依赖拉取 (Dependency)](#3. 如何管理依赖拉取 (Dependency))
- [4. 推荐的规范化研发流程（最佳实践）](#4. 推荐的规范化研发流程（最佳实践）)
一·Release、Snapshot两种包该如何分别管理与发布构建呢？
在 Maven 中，Release（正式版）和 Snapshot（快照/开发版）的管理与发布，核心完全依赖于 版本号（）的命名规范，Maven 底层会根据版本号的后缀自动进行路由和策略处理。
具体来说，你可以通过以下几个方面来分别管理和发布这两种包：
1. 核心开关：版本号命名
Maven 识别包类型的唯一标准是：版本号是否以 -SNAPSHOT（必须全部大写）结尾。
Snapshot 版本：例如 1.0.0-SNAPSHOT。代表这是一个处于开发中、不稳定的版本。
Release 版本：例如 1.0.0 或 1.0.0-RELEASE。只要不带 -SNAPSHOT，Maven 均视其为稳定的正式版。
2. 如何发布构建 (Deploy)
当你执行 mvn deploy 命令进行构建并推送到私服时，你不需要手动指定推送到哪个仓库，Maven 会自动根据版本号判断：
（1）发布 Snapshot： 当前版本号带有 -SNAPSHOT，Maven 会自动找到 下的 配置，将其上传到 libs-snapshots-local 仓库。由于是快照，私服会自动在原包名后追加时间戳（如 1.0.0-20231010.1230），允许多次覆盖发布。
（2）发布 Release： 当前版本号剔除了 -SNAPSHOT，Maven 会自动找到 下的 配置，将其上传到 libs-releases-local 仓库。注意：Release 仓库通常具备只读属性，同版本号的 Release 包一旦发布，就严禁再次覆盖上传。
xml
//项目发布/上传配置
<distributionManagement>
<repository>
<id>libs-releases</id>
<url>
http://xxx/xxx
</url>
</repository>
<snapshotRepository>
<id>libs-snapshots</id>
<name>xxx repository-snapshots</name>
<url>http://xxx/xxx</url>
</snapshotRepository>
</distributionManagement>
//依赖库下载源配置
<repositories>
<repository>
<snapshots>
<enabled>true</enabled>
</snapshots>
<id>xxx-central</id>
<name>libs-releases</name>
<url>http://xxx/xxx</url>
</repository>
<repository>
<snapshots />
<id>snapshots</id>
<name>libs-snapshots</name>
<url>http://xxx/xxx</url>
</repository>
</repositories>3. 如何管理依赖拉取 (Dependency)
当你的其他项目需要引入这两个包时，Maven 的本地缓存机制对这两种包采取了截然不同的管理策略：
（1）管理 Release 包： 一旦本地 Maven 仓库（.m2 目录）下载了 1.0.0 版本的 Release 包，就永远不会再去远程仓库检查更新了。这保证了生产环境依赖的绝对稳定性。
（2）管理 Snapshot 包： 如果你依赖了 1.0.0-SNAPSHOT，Maven 知道这个版本会频繁更新。默认情况下，Maven 每天会去私服检查一次有没有最新的时间戳快照；如果你急需拉取同事刚推上去的代码，可以在执行构建命令时加上 -U 参数（例如 mvn clean compile -U），强制 Maven 立即去私服拉取最新的 Snapshot 覆盖本地代码。
4. 推荐的规范化研发流程（最佳实践）
在实际的企业级项目迭代中，我们通常这样配合使用：
日常开发阶段： 大家都在特性分支开发，把版本号改为 1.0.0-SNAPSHOT，随时可以 mvn deploy，团队成员通过快照频繁互相同步最新的 API 和代码。
发版/上线阶段： 准备上线前，修改 pom.xml，将版本号去掉 -SNAPSHOT，改为 1.0.0。提交代码，并在 Git 上打一个 v1.0.0 的 Tag。通过 CI/CD 流水线执行打包，将这个稳定的代码 deploy 到 Release 仓库供线上服务使用。
发版完成后： 立马修改 pom.xml，将版本号升级为下一个版本的快照，例如 1.0.1-SNAPSHOT，为下一个迭代做准备。
(注：如果你觉得手动改版本号太麻烦，业界通常会使用 versions-maven-plugin 插件的 mvn versions:set -DnewVersion=xxx 命令，或者配合 CI/CD 平台的脚本来自动修改与发布。)