删掉 ~/.m2/repository 中对应依赖路径下的 *.lastUpdated 文件即可解决 mvn compile 因缓存冲突导致的依赖下载失败问题，这是 Maven 硬编码机制——只要该文件存在就跳过远程拉取；也可通过 settings.xml 设置 updatePolicy 为 always 或在 CI 中清理 .lastUpdated 文件。
缓存冲突导致 mvn compile 报错的典型现象
执行 mvn compile 时卡在某个依赖下载阶段，或直接报类似 Could not resolve dependencies for project 的错误，但远程仓库明明有该包；~/.m2/repository/ 下对应路径里存在 *.lastUpdated 文件（比如 obj-test-client-1.1.1.jar.lastUpdated），这是 Maven 缓存机制“记仇”的明确信号——它拒绝重试失败的下载，直到你手动干预。
删 .lastUpdated 文件是最轻量有效的解法
这不是玄学，而是 Maven 的硬编码行为：只要 .lastUpdated 存在，就跳过该 artifact 的远程拉取。修复只需定位并删除它：
- 根据报错中缺失的坐标（如
com.example:obj-test-client:1.1.1），进入~/.m2/repository/com/example/obj-test-client/1.1.1/ - 运行
rm *.lastUpdated - 再执行
mvn compile，Maven 会立刻发起新请求
注意：不要只删 jar 或 pom 文件，必须删掉 .lastUpdated —— 它才是锁死缓存的开关。
避免反复踩坑：改 settings.xml 的 updatePolicy
频繁遇到这类问题，说明你的团队或 CI 环境网络不稳定。与其每次手动删，不如让 Maven 主动“勤快点”：
- 编辑
~/.m2/settings.xml（或全局$MAVEN_HOME/conf/settings.xml） - 在
<repository>或<profile>中添加：<updatePolicy>always</updatePolicy>，同时覆盖<releases>和<snapshots>块 - 生效后，Maven 每次都会检查远程元数据，不再信任本地缓存状态
副作用是编译略慢，但换来的是可预测性——尤其适合 Jenkins 构建或多人共享本地仓库的场景。
CI/CD 流水线里别信本地缓存
Jenkins 或 GitHub Actions 中，如果复用宿主机的 ~/.m2，旧的 .lastUpdated 会被带入新构建，导致“同一份代码，在本地能编，CI 上必挂”。更稳妥的做法是：
- 在流水线脚本开头加
find ~/.m2/repository -name "*.lastUpdated" -delete - 或直接禁用本地缓存：用
mvn -Dmaven.repo.local=/tmp/m2 clean compile强制使用临时仓库 - 若用 Docker，干脆不挂载
~/.m2，让每次构建都干净起步
缓存本为提速而生，但在协作和自动化场景下，它的“记忆”反而成了最隐蔽的故障源——删文件、改策略、隔离环境，三者选其一，比花半小时查日志更高效。
