maven依赖问题需按步骤排查：先确认jdk安装及java_home配置；再清理本地仓库或用命令修复；接着用dependency:tree定位冲突、检查scope和远程仓库；最后通过声明高优版本或exclusion解决冲突，并配置阿里云镜像加速下载。
当你在IDEA里导入一个Maven项目，控制台疯狂刷出“Could not resolve dependencies”或“Dependency not found”，而pom.xml里明明写了正确的坐标，却始终编译失败——这不是你代码写错了，而是依赖管理环节出了系统性偏差。这类问题不解决，连最基础的Spring Boot启动都卡在第一步。
确认JDK是否真正就位
打开终端，执行 java -version，必须看到类似 java version "17.0.8" 的输出；如果提示“命令未找到”或版本低于1.8，Maven根本无法启动，后续所有操作都无意义。
注意：仅安装JRE不行，【必须安装JDK并配置JAVA_HOME指向其根目录】，否则mvn命令会直接报错退出，且错误信息不提示真实原因。
本地仓库损坏时的强制重建
方法一：删掉整个本地仓库目录
进入用户主目录 → 找到 .m2/repository 文件夹 → 彻底删除它（Windows下是 C:\Users\用户名\.m2\repository，Mac/Linux是 ~/.m2/repository）。
方法二：用Maven命令清理缓存
执行 mvn clean dependency:purge-local-repository -Dreleases -Dsnapshots，该命令会清空本地仓库中已解析但可能损坏的依赖元数据，比手动删更安全。
这一步做完后，下次执行 mvn compile 会重新下载所有依赖，首次耗时较长，但能绕过因 _remote.repositories 文件残留导致的“找不到artifact”假象。
精准定位缺失依赖的三层排查法
第一步：运行 mvn dependency:tree -Dverbose，观察输出中是否出现 omitted for conflict 或 omitted for duplicate 字样——这说明有依赖被自动排除，不是没下载，而是被更高优先级版本覆盖了。
第二步：检查pom.xml中该依赖的<scope></scope>是否误设为 provided 或 test，导致在编译或运行时不可见；比如把 mysql-connector-java 设为 provided，打包后运行就会抛 ClassNotFoundException。
第三步：手动验证远程仓库是否存在该坐标
打开浏览器，访问 https://repo1.maven.org/maven2/{groupId}/{artifactId}/{version}/（将{groupId}中的点替换为斜杠，如 org.springframework → org/springframework），确认页面返回200且包含 {artifactId}-{version}.jar 文件链接。
解决依赖冲突的两种实战策略
策略一：显式声明高优版本
在pom.xml的 <dependencies></dependencies> 块顶部，直接添加你想要的版本，Maven按声明顺序取第一个匹配项，后面同名依赖会被忽略。
策略二：用exclusion精准剔除干扰项
比如某第三方SDK自带旧版log4j，而你项目要求log4j2，就在该SDK的dependency块内加入 <exclusions><exclusion><groupid>log4j</groupid><artifactid>log4j</artifactid></exclusion></exclusions>，避免传递依赖污染。
【exclusion只作用于当前dependency的传递链，不影响其他直接声明的依赖】，这点务必记清，否则可能误删关键基础包。
加速依赖下载的镜像配置实操
编辑 ~/.m2/settings.xml（若不存在则新建），在 <mirrors></mirrors> 标签下插入阿里云镜像：
<mirror></mirror><id>aliyunmaven</id><mirrorof>central</mirrorof><name>Aliyun Maven</name><url>https://maven.aliyun.com/repository/public</url>
保存后无需重启IDE，下次执行mvn命令会自动走镜像源；国内用户平均提速3～5倍，尤其对spring-boot-starter等大体积starter效果显著。
