maven snapshot依赖不更新需检查updatepolicy配置是否在repository块中生效，其值为always、daily、interval:xx或never，且仅对对应仓库有效；-u可临时强制更新。
snapshot 依赖不更新？检查 updatePolicy 配置是否生效
默认情况下，Maven 对 SNAPSHOT 版本依赖只在本地构建时检查一次远程仓库，之后就用缓存的副本——这不是 bug，是设计行为。关键在于 updatePolicy 控制“什么时候去远端拉新快照”，它只在 repository 或 pluginRepository 的 <snapshots></snapshots> 块里起作用，且仅对该仓库生效。
常见错误现象：mvn clean compile 后依然用着旧的 mylib-1.0.0-SNAPSHOT.jar，哪怕 Nexus 上已部署了新时间戳版本。
-
updatePolicy可选值只有四个：always、daily（默认）、interval:XX（单位分钟，如interval:30）、never - 写成
hourly或onetime这类非标准值会被静默忽略，回退到daily - 该配置必须放在
<repositories><repository><snapshots><updatepolicy></updatepolicy></snapshots></repository></repositories>路径下，放在<dependencies></dependencies>或<profiles></profiles>里无效 - 命令行加
-U（即mvn -U compile）会强制触发所有 snapshot 更新，但只是临时绕过，不是长期解法
多仓库场景下，每个 repository 的 snapshot 策略独立生效
如果你的 pom.xml 同时声明了 Nexus 私服和阿里云 Maven 镜像，而后者也托管了某些 SNAPSHOT 包（比如某些开源实验分支），那么两个仓库的 <snapshots></snapshots> 配置互不影响。Maven 会按 <repositories></repositories> 声明顺序查找依赖，一旦在某个仓库命中 SNAPSHOT，就只查那个仓库的策略。
使用场景：公司私服启用了 updatePolicy=always，但你又在 <repositories></repositories> 底部追加了 central 镜像并没关它的 snapshots——结果可能从 central 拉到过期快照，因为它的默认策略是 daily。
- 务必确认你要用的快照包实际发布在哪个仓库，然后只在那里配
updatePolicy - 如果某仓库根本不提供 SNAPSHOT（比如纯 release 仓库），建议显式关闭：
<snapshots><enabled>false</enabled></snapshots> - 避免在
<mirrorof>*</mirrorof>的镜像配置中开启 snapshots，否则会覆盖所有仓库策略
timestamped 文件名与本地仓库缓存机制的关系
Maven 下载 SNAPSHOT 时，不会直接保存为 mylib-1.0.0-SNAPSHOT.jar，而是用时间戳重命名，例如 mylib-1.0.0-20240521.093322-1.jar，同时在本地仓库写一个 maven-metadata.xml 文件记录最新时间戳。本地构建时，Maven 先读这个元数据，再决定用哪个时间戳文件。
容易踩的坑：手动删了 mylib/1.0.0-SNAPSHOT/ 目录下的 jar 却没删 maven-metadata.xml，下次构建仍会加载旧时间戳；或者 CI 机器没清理本地仓库，导致元数据指向的是上周的构建。
- 真正可靠的清理方式是：
mvn dependency:purge-local-repository -DmanualInclude=mygroup:mylib -
maven-metadata.xml里的<lastupdated></lastupdated>时间戳，是 Maven 决定是否发起 HTTP HEAD 请求检查远端更新的依据 - 不要依赖 IDE 的“Reload project”按钮来刷新 SNAPSHOT——它通常只触发 pom 解析，不触发 metadata 检查
CI/CD 流水线里 SNAPSHOT 更新失败的典型原因
流水线跑 mvn deploy 后，下游模块却拉不到最新快照，大概率不是策略没配，而是环境隔离问题：CI agent 的本地仓库路径与开发机不同，且没有共享元数据状态。
性能影响：设成 always 会让每次构建都发 HTTP 请求查远端 metadata，若仓库网络延迟高或并发大，会拖慢整体构建速度；但设成 interval:10 又可能导致测试环境滞后 10 分钟以上。
- 推荐 CI 使用固定本地仓库路径（如
-Dmaven.repo.local=/ci/.m2），并确保每次构建前 purge 相关依赖 - 避免在 CI 中启用
settings.xml里的全局mirrorOf=*，它可能把快照请求意外转发到不支持 snapshot 的镜像站 - 最隐蔽的问题：私服（如 Nexus）的
SNAPSHOT仓库策略本身设成了“禁止覆盖”，此时即使客户端策略正确，上传也会失败，下游自然拉不到新版本
快照更新不是单点配置问题，它横跨客户端策略、服务端权限、网络路由、本地缓存三者。少盯一个环节，就会卡在“明明改了却没生效”的状态里。
