Maven 构建以 pom.xml 为核心，settings.xml 仅影响依赖获取方式而非定义依赖；pom.xml 必须正确定义 groupId、artifactId、version、packaging 及依赖范围、插件配置等，父子模块需正确设置 relativePath 或确保父 POM 已安装至本地仓库。
Maven 的配置核心在 pom.xml，不是改 settings.xml 就能跑通项目
为什么改了 settings.xml 还是下载不了依赖？
常见误区是以为配好本地仓库路径或镜像源就万事大吉。实际项目构建时，Maven 优先读取项目根目录下的 pom.xml；只有当它声明了依赖、插件、profile 或需要访问私有仓库时，才轮到 settings.xml 起作用。
-
settings.xml只影响「如何获取依赖」（比如用哪个镜像、认证凭据），不定义「要拿什么依赖」 - 如果
pom.xml里写的是spring-boot-starter-web，但没声明spring-boot-starter-parent父 POM 或对应dependencyManagement，版本就会丢失，导致编译失败 - 公司私有仓库需在
settings.xml的id，同时在pom.xml的id，否则认证不生效
pom.xml 中哪些元素不能省，又容易写错？
最小可运行的 Java 项目至少要包含 groupId、artifactId、version 和 packaging（默认 jar）。但实际开发中，漏掉或误配以下几项最常引发问题：
-
java.version不等于设置编译级别——必须配合maven-compiler-plugin的 -
test范围的junit-jupiter写成默认compile，会导致测试代码打进生产包 -
→ maven-surefire-plugin不显式启用enableAssertions，断言可能被 JVM 忽略
多模块项目中，父 POM 的 relativePath 怎么填才不报错？
错误现象：Could not find artifact xxx:pom:1.0.0 in central，但明明父模块就在上层目录。根本原因是 Maven 默认只在 ../pom.xml 找父 POM，不会递归向上搜索。
立即学习“Java免费学习笔记（深入）”；
- 如果父 POM 在当前模块的上两级目录（如
./submodule/pom.xml→ 父在../pom.xml），则../pom.xml - 若父 POM 已安装到本地仓库（
mvn install过），可删掉 - IDE（如 IntelliJ）有时缓存旧的 relativePath，修改后需右键项目 →
Maven → Reload project，否则仍按旧路径解析
真正卡住人的往往不是语法，而是 pom.xml 和 settings.xml 的职责边界模糊、父子模块路径解析机制不透明、以及 IDE 缓存和命令行行为不一致——这些地方不手动验证，光看文档容易绕晕。
