先检查pom.xml中依赖坐标是否正确，再执行mvn compile等命令触发下载，确认settings.xml镜像配置无误，快照版本用-U强制更新，优先根据错误日志定位问题。
依赖没下载成功，先看 pom.xml 里写对了没
很多情况下“下载不了”根本不是网络或仓库问题，而是 dependency 声明本身有误。常见错误包括：
— groupId、artifactId 拼错（比如把 slf4j-api 写成 slf4j-apii）
— version 用的不是中央仓库真实存在的版本（例如写 2.0.0 但最新只有 2.0.13）
— 缺少 scope 导致被意外排除（如测试依赖漏写 test）
— 使用了私有坐标但没配对应 repository
执行 mvn clean compile 才真正触发下载
Maven 不会在你保存 pom.xml 后自动拉取依赖，必须运行带生命周期阶段的命令：
— mvn compile：编译主代码，同时解析并下载运行时和编译期依赖
— mvn test：额外下载 test scope 的依赖
— mvn dependency:resolve：只解析依赖树，不编译，适合快速验证是否可解析
注意：mvn clean 单独运行不会触发下载，它只是删掉 target/
下载失败时检查 settings.xml 和镜像配置
国内用户最常卡在这一步。Maven 默认走 Maven Central（https://repo.maven.apache.org），但实际可能被重定向到阿里云、腾讯云等镜像：
— 确认 ~/.m2/settings.xml 中 mirrorOf 值为 central 或 *）
— 如果用的是公司 Nexus/Artifactory，要确保 id 和认证信息（必要时在 username/password）
— 错误提示含 Could not transfer artifact ... from/to central，基本说明仓库连通性或权限有问题
mvn -U 强制更新快照依赖，但别滥用
对于 SNAPSHOT 版本（如 1.0.0-SNAPSHOT），Maven 默认每天只检查一次远程更新。如果本地已缓存旧版快照，又想立刻拉新：
— 运行 mvn -U compile，强制刷新所有快照依赖
— 但这个参数对非快照版本无效，也不会重新下载已成功的稳定版
— 频繁加 -U 会拖慢构建，尤其在 CI 环境中，应优先靠版本号管理而非依赖刷新
立即学习“Java免费学习笔记（深入）”；
依赖下载这件事，表面是网络和配置问题，实际往往卡在坐标拼写、scope 作用域理解、或者误以为“保存 pom 就等于下载完成”。真出问题时，先看控制台输出的完整错误路径和 artifact 坐标，再反查pom.xml 和 settings.xml——比换镜像或清缓存更省时间。 
