本地私有Maven仓库该配在哪儿
Maven 默认会把依赖下载到 ~/.m2/repository（Linux/macOS）或 C:\Users{user}.m2\repository（Windows），但这只是本地缓存，不是“私有仓库”。真要建私有仓库，得用 Nexus、Artifactory 或简单点的 Maven 本地 HTTP 服务——但多数团队误以为改个 settings.xml 就算搭好了，结果同事拉代码还是连中央仓库。
- 私有仓库本质是独立运行的服务，监听一个 HTTP 地址（比如
<a href="https://www.php.cn/link/97a34e8859e946b5313f18f5f5f4c9f6">https://www.php.cn/link/97a34e8859e946b5313f18f5f5f4c9f6</a>或内网地址） -
settings.xml里配的是「去哪里下载」和「往哪部署」，不是「仓库本身在哪」 - 如果只是想让多个项目共享一份 jar（避免重复下载），直接共用
~/.m2/repository目录就行，不用额外搭服务
settings.xml 中 mirror 和 profile 的典型误配
很多人复制网上配置，把 <mirror></mirror> 指向自己还没启动的 Nexus 地址，然后 mvn clean compile 直接卡住或报 Could not transfer artifact。
-
<mirror></mirror>是全局拦截：所有central请求都会被重定向，一旦目标不可达，整个构建就失败 - 更稳妥的做法是用
<profile></profile>+<repository></repository>显式声明私有源，再用<activeprofiles></activeprofiles>控制启用时机 - 避免把私有仓库同时设为
<mirrorof>*</mirrorof>—— 这会让 JCenter、Spring Plugins 等其他仓库也失效
<profile>
<id>private-repo</id>
<repositories>
<repository>
<id>my-nexus</id>
<url>http://nexus.internal:8081/repository/maven-public/</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>false</enabled></snapshots>
</repository>
</repositories>
</profile>
deploy 到私有仓库时 401 Unauthorized 怎么解
mvn deploy 报 401，通常不是密码错了，而是没配对三样东西：
-
settings.xml里<servers></servers>下的<server></server>id必须和pom.xml中<distributions><repository></repository></distributions>的id完全一致立即学习“Java免费学习笔记（深入）”；
Nexus/Artifactory 对应的 repository 必须开启 Deployment（默认很多是 disabled）
账号得有
nx-repository-view-<em>-</em>-add权限，光有 read 不行别在
settings.xml里明文写密码，用mvn --encrypt-password加密后填进<password></password>如果用 Nexus 3.x，
<url></url>结尾必须带/repository/{repo-name}/，少一级路径就会 405 Method Not Allowed
CI 环境下本地仓库路径容易被清空
Jenkins 或 GitHub Actions 每次跑构建都新建 workspace，~/.m2/repository 是空的，导致重复下载、构建变慢，甚至触发 Nexus 的 rate limit。
- 在 CI 脚本里显式配置
-Dmaven.repo.local=/path/to/shared/.m2，指向一个跨 job 复用的目录 - GitHub Actions 可用
actions/cache缓存~/.m2/repository，但注意 cache key 要包含mvn -v和settings.xmlhash，否则不同 JDK 或配置混用会出错 - 不建议在
pom.xml里硬编码<localrepository></localrepository>，这会让本地开发和 CI 行为不一致，排查问题时容易漏掉这个差异
私有仓库不是配完 settings.xml 就万事大吉的事——它是个活的服务，得有人管它的可用性、权限、清理策略。最常被跳过的一步，是上线前没验证 mvn deploy 后的 jar 是否真能被另一个空环境的 mvn dependency:get 正确拉下来。
