这是个典型的Maven组件升级带来的兼容性问题，我来给你拆解清楚：

核心原因：Wagon版本的认证逻辑变化 #

你已经定位到问题出在Maven 3.5.0及以上版本——没错，Maven 3.5.0把内置的Wagon组件从2.10升级到了2.12，而新版本的Wagon在和Artifactory交互时，认证凭据的加载逻辑和旧版本有差异，这就导致了两种部署命令的行为不同：

两种命令的差异点 #

• mvn deploy:deploy-file：你直接通过命令行参数-DrepositoryId指定仓库ID，这种直接调用插件的方式，Wagon会直接从settings.xml里匹配对应ID的凭据，这个逻辑在新旧Wagon版本里都保持了兼容性，所以能正常执行。
• mvn deploy：这是触发完整的Maven生命周期，会从POM里读取distributionManagement的仓库配置，再去匹配settings.xml的凭据。而Wagon 2.12+在处理这个流程时，对凭据的匹配逻辑做了调整（比如更严格的ID大小写检查、凭据传递方式变化），导致Artifactory识别不到有效授权，返回401错误。

你的临时修复为什么生效？ #

你在POM里添加的wagon-http扩展，相当于强制Maven在执行完整生命周期时使用旧版本（2.10）的Wagon组件，回到了和Artifactory兼容的认证逻辑，所以mvn deploy就恢复正常了。

额外优化建议 #

如果不想一直依赖旧版Wagon，可以试试这些方案：

• 仔细核对settings.xml里的<server>仓库ID，和POM中distributionManagement配置的仓库ID是否完全一致（大小写敏感！）
• 确认settings.xml里的用户名、密码（或者加密凭据）配置正确
• 把Artifactory升级到最新版本，官方通常会修复和高版本Maven/Wagon的兼容性问题

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