Maven部署时未添加Authorization请求头问题咨询

这绝对不是Maven的正常行为——按照预期，只要你在settings.xml里正确配置了对应仓库的认证信息，Maven应该自动为请求添加Authorization头。命令行参数能成功反而说明仓库的Basic Auth本身没问题，问题大概率出在你的配置匹配或者细节上。下面是几个最常见的排查方向：

• 确认settings.xml的位置与server配置匹配
  Maven优先读取用户目录下的~/.m2/settings.xml，其次是Maven安装目录下的conf/settings.xml，别不小心修改了错误的文件。另外，server标签的id必须和pom.xml中distributionManagement里仓库的id完全一致（大小写敏感），这是最容易踩的坑。比如pom里配置：

  <distributionManagement>
    <repository>
      <id>protected-repo</id>
      <url>https://your-repo-url/releases</url>
    </repository>
  </distributionManagement>
  

  那settings.xml里的server必须对应：

  <servers>
    <server>
      <id>protected-repo</id>
      <username>your-account</username>
      <password>your-pass</password>
    </server>
  </servers>
  

• 检查密码的特殊字符或加密问题
  如果密码包含XML特殊字符（比如&, <, >），直接写入会导致XML解析失败，这时候需要转义（比如&换成&），或者用Maven的密码加密功能：执行mvn --encrypt-password your-pass生成加密后的密码，再配置到settings里，同时确保master password的配置正确。

• 排查Maven版本或缓存干扰
  部分旧版本Maven存在Basic Auth处理的bug，建议升级到3.8.x及以上的稳定版本。另外，清理Maven缓存试试：删除~/.m2/repository下的相关缓存目录，或者执行mvn clean deploy -U强制更新依赖，避免旧缓存的认证信息干扰。

• 检查代理或网络拦截
  如果你的网络有公司代理，代理可能会拦截Authorization头，或者需要单独在settings.xml里配置代理的认证信息。另外，确认Wireshark抓包的是Maven发出的请求，排除其他网络工具的干扰。

简单来说，命令行参数能成功是因为它直接绕过了settings的匹配逻辑，把参数直接作为认证信息传入，所以核心问题还是settings与pom的配置匹配没做好，先重点核对server id和仓库id的一致性！

内容的提问来源于stack exchange，提问作者Dmytro Titov