私服已经上传新的 Snapshot，Jenkins 构建结果却没有变化，是一次旧项目中遇到的依赖缓存问题。版本名带 -SNAPSHOT，并不代表 Maven 每次都无条件下载新内容；还要看有效仓库和更新策略。

明确 Snapshot 仓库的配置层级

放在 pom 的 repositories 中时，配置结构可以是：

<repositories>
  <repository>
    <id>internal-snapshots</id>
    <url>https://repo.example.com/repository/snapshots/</url>
    <releases>
      <enabled>false</enabled>
    </releases>
    <snapshots>
      <enabled>true</enabled>
      <updatePolicy>always</updatePolicy>
    </snapshots>
  </repository>
</repositories>

地址只是示例。认证信息应在受保护的 settings/凭据机制中配置，不直接提交密码。若写在 settings 中，repositories 还要处在合适的 profile 之下，并确认该 profile 实际启用。

updatePolicy 可选 always、daily、interval:分钟数 和 never。always 表达每次需要时检查更新，不保证错误仓库、代理缓存或未成功发布的构件突然变成正确内容。Maven 仓库策略

一次性检查可以使用 -U

需要对某次构建检查远端更新时：

mvn -U clean verify

如果 Jenkins 已经提供 Maven 的目标字段，填写 -U clean verify，不再重复 mvn。项目使用 Wrapper 时，可在 Shell 中调用 ./mvnw -U clean verify。

Maven 的 -U 强制检查远端缺失的 release 和已更新的 snapshot；它不是删除整个缓存，也不是强制重新下载每个已有 release。Maven CLI 选项

从有效配置检查到实际产物

还未拿到预期版本时，依次确认：

  1. 依赖坐标和版本确实指向目标 Snapshot，而非另一个模块或 release。
  2. Jenkins 使用了预期 settings、镜像规则、profile 和本地仓库位置，没有离线模式。
  3. 构建日志中的下载仓库，是上传新构件的仓库或正确代理。
  4. 远端元数据和文件确已发布成功，代理缓存及访问权限没有挡住更新。
  5. 最终依赖树及产物内容，确实包含预期版本，而非只看“有下载日志”。

help:effective-pom、help:effective-settings 可辅助检查有效配置，但输出可能含内部地址和配置，应脱敏保存；不要直接公开整份 settings 或带调试参数的日志。

不把刷新策略当成可复现发布策略

always 和 -U 会增加远端检查与私服压力，也不能让不断变化的 Snapshot 变成不可变产物。日常开发可按需要设更新频率；正式发布应保留明确版本、源码提交和产物标识，不能仅靠“构建时取最新”保证可追溯。