<p>核心原因是 mirrorOf 配置覆盖私服，如 * 会拦截全部请求；需精确匹配 mirrorOf、确保私服在 profiles 中激活、server ID 严格一致，并由私服代理中央仓库实现缓存。</p>
为什么 settings.xml 里配置了私服却还是拉不到依赖
核心原因通常是 mirrorOf 配置覆盖了私服地址，导致所有请求被重定向到中央仓库或其它镜像。Maven 默认的 mirrorOf * 会拦截全部请求，包括你显式声明的私服 repository。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 检查
~/.m2/settings.xml中<mirrors>下是否含<mirrorOf>*</mirrorOf>，如有，改为更精确的匹配，例如<mirrorOf>central</mirrorOf>或<mirrorOf>!nexus-internal,*</mirrorOf>（排除 ID 为nexus-internal的仓库） - 确保私服仓库定义在
<profiles>内，并通过<activeProfiles>激活，而非仅靠<repositories>直接写在根节点下（后者在 settings.xml 中不生效） - 私服
id必须与<mirror>的<mirrorOf>值或<profile>中<repository>的id严格一致，大小写敏感
如何让 Maven 同时使用中央仓库 + 私服做代理和缓存
正确做法是把私服设为唯一远程仓库入口，由它代理中央仓库和其他外部源（如 Spring Plugins、JCenter 归档源等），而不是在项目中并列声明多个 <repository>。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 在 Nexus/Artifactory 控制台中，为私服创建一个
group类型仓库（如public），按顺序添加central、spring-plugin-releases、nexus-internal等成员仓库 - 在
settings.xml的<profiles>中只声明该group仓库，<id>设为public，URL 指向http://your-nexus/repository/public/ - 禁用项目
pom.xml中的<repositories>—— 否则会绕过私服，直接连外网，失去缓存和审计能力
mvn deploy 失败提示 “Authentication failed for https://…” 怎么调
这是认证凭据未正确绑定到私服 id，或服务器端权限未开放部署权限。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 确认
settings.xml的<servers>区块中，<server>的<id>与pom.xml中<distributions><repository>的<id>完全一致 - 使用
mvn -X deploy查看 DEBUG 日志，确认 Maven 实际读取的是哪个serverID，以及是否加载了对应<username>和<password> - Nexus 管理后台需为该用户分配
nx-repository-view-*-*-add和nx-repository-view-*-*-edit权限（针对目标仓库），仅read权限无法部署 - 密码不要明文写在
settings.xml，应使用mvn --encrypt-password加密后填入<password>
私有依赖 SNAPSHOT 版本更新不及时怎么办
默认情况下，Maven 对 SNAPSHOT 依赖每天只检查一次远程更新（daily 策略），本地有缓存就直接用，不会实时拉取最新构建。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 在
settings.xml的<profiles>中，为私服仓库指定<updatePolicy>always</updatePolicy>（仅限开发环境，勿用于 CI） - 更稳妥的方式：在
pom.xml的<dependencies>中对特定 SNAPSHOT 依赖加<scope>import</scope>并配合<version>1.0.0-SNAPSHOT</version>，再执行mvn clean compile -U（-U强制更新快照） - 避免在
releaseprofile 下保留 SNAPSHOT 依赖，CI 流水线应拒绝含-SNAPSHOT的version进入制品库
私服不是“多配一个 URL”就完事的事。真正卡点往往在 mirror 优先级、server ID 绑定、Nexus 权限粒度和 SNAPSHOT 缓存策略这四层嵌套逻辑里——漏掉任意一层，都会表现为“明明配了却没走私服”。
