gcloud Artifact Registry 无法解析Maven私有制品依赖求助

前置排查结论：你已经验证同仓库其他历史制品可正常拉取，说明仓库地址配置、GCP身份认证连通、网络链路这类基础环节全部正常，完全不需要重复排查这类通用问题，所有故障点都集中在新制品的发布、坐标匹配、快照拉取规则配置环节。

逐点排查操作 #

• 核对制品坐标的完全匹配性
  直接打开GCP Artifact Registry控制台，进入对应仓库的文件目录，定位到com/company/group/artifact/路径下，对比实际存储的groupId、artifactId、version、打包类型，和你项目pom里写的com.company.group:artifact:jar:1.0-SNAPSHOT有没有细微差异：
  • 常见差异点：大小写不一致、groupId多了或少了层级分隔符、打包类型不匹配（比如实际打的是war包但项目里配的是jar）
  • 注意SNAPSHOT版本的存储规则：Maven部署SNAPSHOT制品时，默认会在目录下追加带时间戳的版本文件，依靠同目录下的元数据索引来映射1.0-SNAPSHOT的别名，一旦元数据文件缺失，就算jar包已经传到仓库，Maven也会报找不到制品。
• 检查Maven仓库的快照拉取开关配置
  不管是你在项目pom里配的<repository>节点，还是在settings.xml里配的对应仓库配置，必须确保SNAPSHOT拉取开关是打开的，正确配置参考：

  <repository>
    <id>你的AR仓库ID</id>
    <url>artifactregistry://europe-maven.pkg.dev/项目名/仓库名</url>
    <snapshots>
      <enabled>true</enabled>
    </snapshots>
  </repository>
  

  很多人只配了仓库地址没开这个开关，会导致Maven直接跳过所有快照版本制品的拉取请求，哪怕仓库里已经存了对应的包也会报找不到。
• 验证制品上传的完整性
  打开AR对应SNAPSHOT版本的存储目录，检查必须存在的三类文件：
  • 制品本身的jar/war包
  • 和制品版本完全同名的.pom元数据文件
  • 目录下的_maven-metadata.xml索引文件
    三类文件缺任意一个，Maven都无法识别到这个制品。如果发现是上传中断导致的文件缺失，直接重新执行一次mvn deploy命令，确保所有文件完整上传即可。
• 排查本地缓存的更新策略冲突
  如果你本地的Maven配置里给AR仓库设置了<updatePolicy>never</updatePolicy>，就算你重新上传了新的SNAPSHOT制品，Maven也不会主动刷新本地存储的仓库索引，始终用旧的索引判断仓库里不存在这个制品。清理本地缓存时，除了删除~/.m2/repository下的对应制品目录，还要同步删除~/.m2/repository目录下缓存的AR仓库元数据文件，再重新执行依赖拉取即可。

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