1.Maven私库（私服）
定义
私有仓库，企业内部搭建的Maven仓库
用于存储和管理企业内部的二方包和第三方依赖
作用
text
中央仓库（公网） ↓ Maven私库（内网） ←─→ 开发团队 ↓ 项目构建
加速构建：缓存中央仓库依赖，减少外网下载
隔离性：企业内部代码不上传到公共仓库
统一管理：企业内所有项目的依赖统一版本管理
发布平台：二方包发布和分发的平台
2.二方包 Release 版本
特点
版本号固定：如
1.0.0、2.1.3稳定性高：经过测试的正式版本
不可修改：一旦发布到私库，内容不可更改
发布流程严格：通常需要代码评审、测试等流程
Maven坐标示例
xml
<dependency> <groupId>com.company</groupId> <artifactId>common-utils</artifactId> <version>1.2.0</version> </dependency>
发布到私库
bash
mvn clean deploy -Dmaven.test.skip=true
3.二方包 Snapshot 版本
特点
版本号带 SNAPSHOT 后缀：如
1.0.0-SNAPSHOT开发中版本：不稳定，还在开发阶段
可覆盖：同一版本可多次部署，覆盖旧版本
自动更新：Maven会定期检查更新（默认每天）
Maven坐标示例
xml
<dependency> <groupId>com.company</groupId> <artifactId>common-utils</artifactId> <version>1.2.0-SNAPSHOT</version> </dependency>
更新机制
bash
# 强制更新SNAPSHOT依赖 mvn clean install -U
4.三者的核心区别对比
| 特性 | Snapshot版本 | Release版本 | Maven私库 |
|---|---|---|---|
| 版本命名 | 带-SNAPSHOT后缀 | 纯数字版本号 | 仓库概念，无版本 |
| 稳定性 | 开发中，不稳定 | 稳定，经过测试 | 基础设施 |
| 可覆盖性 | ✅ 可覆盖部署 | ❌ 不可覆盖 | 存储介质 |
| 更新策略 | 定期检查更新 | 除非手动升级，否则不变 | 版本管理平台 |
| 使用场景 | 联调、持续集成 | 正式环境、生产发布 | 所有版本存储 |
| 部署频率 | 频繁，每次提交都可部署 | 按发布周期 | 持续接收 |
| 时间戳 | 带时间戳，如1.0-20240126.102030-1 | 无时间戳 | 记录所有版本 |
5.实际工作流程示例
开发阶段
发布阶段
版本演进示例
text
1.0.0-SNAPSHOT → 1.0.0 → 1.0.1-SNAPSHOT → 1.0.1 ↑ ↑ ↑ 开发阶段 发布版本 修复bug开发
6.配置示例
pom.xml 中的发布配置
xml
<distributionManagement> <!-- Release版本仓库 --> <repository> <id>company-releases</id> <url>http://nexus.company.com/repository/maven-releases/</url> </repository> <!-- Snapshot版本仓库 --> <snapshotRepository> <id>company-snapshots</id> <url>http://nexus.company.com/repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement>
私库镜像配置（settings.xml）
xml
<mirrors> <mirror> <id>company-nexus</id> <mirrorOf>*</mirrorOf> <url>http://nexus.company.com/repository/maven-public/</url> </mirror> </mirrors>
7.最佳实践
开发期用SNAPSHOT：团队内部联调使用SNAPSHOT版本
发布用Release：上线前必须切换为Release版本
版本管理规范：
主版本.次版本.修订版本
如：
2.1.3（2是大版本，1是功能版本，3是bug修复）
私库管理：
定期清理旧的SNAPSHOT版本
Release版本永久保留
设置权限控制
总结
私库是基础设施，提供存储和管理能力
Snapshot是开发中的"活"版本，用于持续集成
Release是稳定的"死"版本，用于生产环境
三者共同构成了企业级Maven依赖管理的完整体系
