dependencyManagement是多模块项目的必选项，因其在父POM中集中声明版本契约，子模块省略version时自动继承，显式声明则覆盖，确保全项目依赖版本统一且可管控。
为什么 dependencyManagement 是多模块项目的必选项
在大型多模块项目中，靠每个子模块各自声明版本或用 <exclusions> 逐个排除，很快就会失控。根本原因在于：Maven 的依赖调解规则（最短路径优先、声明顺序优先）只决定“最终选哪个版本”，但不保证“所有模块用同一个版本”。dependencyManagement 不参与实际依赖引入，只提供版本契约——它让父 POM 成为版本事实源，子模块哪怕不写 <version>，也能按统一规则解析。
dependencyManagement 的正确声明位置和生效范围
必须放在父 POM 的 <dependencyManagement> 块中，且该父 POM 要被所有子模块继承（即子模块的 <parent> 指向它）。注意以下关键点：
- 子模块中若显式写了
<version>，会覆盖dependencyManagement中的声明（这是设计行为，不是 bug） -
dependencyManagement中的依赖不会自动引入到子模块，子模块仍需在自己的<dependencies>中声明<groupId>和<artifactId>，才能真正拉取 - 如果项目用了多个 BOM（比如 Spring Boot + 公司内部 BOM），后声明的
<dependencyManagement>会覆盖前面的，顺序很重要
如何避免 dependencyManagement 引发的新问题
常见踩坑点不是“没加”，而是加得不完整或逻辑混乱：
- 只管了主依赖，漏掉其传递依赖：例如统一了
guava版本，但guava的间接依赖jsr305还在各处乱飞，得一并管住 - 版本锁定过死：把
spring-boot-dependencies里已管理的依赖（如jackson-databind）又在自己dependencyManagement里重复声明，反而可能绕过 Spring Boot 的兼容性校验 - 未约束
<scope>：比如把test范围的依赖也放进dependencyManagement，会导致子模块即使不写<scope>也被强制为 test，编译失败 - 忽略
importBOM 的嵌套：公司级 BOM 本身应通过<type>pom</type><scope>import</scope>引入 Spring Boot BOM，而不是手动复制它的全部依赖列表
验证 dependencyManagement 是否真正起效
光看 pom 写对了没用，必须验证运行时实际加载的是哪个版本：
- 执行
mvn dependency:tree -Dverbose -Dincludes=groupId:artifactId，确认输出中不再出现“omitted for conflict”字样，且所有路径都指向同一版本 - 在子模块中故意删掉某个依赖的
<version>，检查是否仍能正常编译——如果报错，说明dependencyManagement没生效或没覆盖到 - 启动应用后，用
ClassLoader.getSystemResource("META-INF/MANIFEST.MF")或 JFR/Arthas 查看实际加载的 jar 包路径和版本，防止构建时正确、运行时被 classpath 顺序覆盖
最易被忽略的是：dependencyManagement 只约束版本，不解决 API 不兼容。比如强制把 jackson-databind 升到 2.15.x，但某 SDK 内部硬编码调用了 2.12.x 才有的私有方法，照样 NoSuchMethodError。这时候得配合 <exclusions> 或升级 SDK 本身。
