dependencyManagement 和 dependencies 有什么区别？BOM 有什么作用？

简化版

dependencies 会真正引入依赖（把它加进当前模块的依赖图，影响编译/测试/运行/传递）；dependencyManagement 只集中管理版本和 scope 默认值，不会真正引入依赖——它像一份「版本目录」，子模块在 dependencies 里声明用哪个 artifact 时可以省略 version，由管理区补齐。BOM（Bill of Materials，物料清单） 是一个 packaging 为 pom 的版本清单，通过 scope=import 导入到 dependencyManagement，用来让一批相关组件的版本保持一致且经过兼容测试（如 Spring Boot、Spring Cloud 的 BOM）。

详细版

dependencies vs dependencyManagement 对比：

	`dependencies`	`dependencyManagement`
作用	真正引入依赖	只声明版本/scope，不引入
影响 classpath	是	否
子模块继承后	直接可用	需在 `dependencies` 声明才生效（可省 version）
含义	「我要用这个库」	「谁用这个库，默认用这个版本」

父 POM + 子模块的配合：

<!-- 父 POM：只管版本 -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>31.1-jre</version>
    </dependency>
  </dependencies>
</dependencyManagement>

<!-- 子模块：声明要用，不写 version（由父 POM 补齐） -->
<dependencies>
  <dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
  </dependency>
</dependencies>

BOM 的导入方式（只能放 dependencyManagement）：

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-dependencies</artifactId>
      <version>3.2.0</version>
      <type>pom</type>
      <scope>import</scope>   <!-- 导入这份 BOM 的所有版本 -->
    </dependency>
  </dependencies>
</dependencyManagement>

插件版本不归 dependencyManagement 管，要用 pluginManagement。

完整版教学

一、两块配置的角色差异（最核心）

dependencies 表示「我要用这个库」——Maven 会把它加入当前模块的依赖图，影响编译、测试、运行、传递。
dependencyManagement 表示「如果某个模块要用这个库，默认用这个版本」——它不会主动改变任何 classpath，只是登记版本。

这个区别是很多新手的误区来源：以为「父 POM 的 dependencyManagement 里写了某个依赖，子模块就自动能用」——错。dependencyManagement 只管版本，子模块必须自己在 dependencies 里声明要用它（只是可以不写 version），依赖才会真正进入 classpath。

配置块	是否进入 classpath	主要作用	典型说法
`dependencies`	是	真正引入依赖	我要用这个库
`dependencyManagement`	否	管版本/scope 默认值	谁用就用这个版本
BOM import	否	批量导入版本表	这组库按这套版本搭配

记住一句工程判断：dependencyManagement 和 BOM 都是“版本账本”，不是“购物车”；真正放进项目的是 dependencies。

二、继承场景下怎么生效

标准的多模块用法：

父 POM 在 dependencyManagement 里统一声明版本。
子模块 在 dependencies 里声明要用的 artifact，省略 version。
Maven 合成 effective POM 时，把管理区的版本补进去。

父 POM dependencyManagement: guava -> 31.1-jre
子模块 dependencies: guava（不写 version）
effective POM: guava -> 31.1-jre

好处：版本在一个地方（父 POM）维护，改一处全模块生效；同时子模块的依赖仍然是显式声明的（谁用了什么一目了然，不会「继承一堆用不到的依赖」）。这就是「版本集中管理、依赖显式声明」的最佳实践。

三、BOM 的本质：一份经过维护的版本表

BOM（Bill of Materials） 不是什么魔法依赖包，它本质是一个 packaging 为 pom 的文件，里面只有一大堆 dependencyManagement 版本声明，没有实际代码。

导入方式固定：<type>pom</type> + <scope>import</scope>，且只能放在 dependencyManagement 里。导入后，这份 BOM 里管理的所有版本就并入了你的 dependencyManagement，你在 dependencies 里用这些库时都不用写版本了。

典型的 BOM：Spring Boot 的 spring-boot-dependencies、Spring Cloud 的 BOM、Netty 的 BOM、Jackson 的 BOM 等。它们把一整套相关组件的版本坐标打包在一起。

四、为什么 BOM 能降低兼容风险

很多框架不是单个 jar，而是一组模块协同工作——比如 Spring Boot 有 starter、Spring Core、Tomcat、Jackson、日志等几十个组件。如果手工逐个升级其中某个模块，很容易造成版本之间 API 或行为不匹配（比如升了 Spring 但没升配套的 Jackson，导致运行异常）。

BOM 的价值在于：维护者已经给出一套「互相兼容、经过组合测试」的版本坐标。你优先沿用 BOM 给的版本，就能避免自己拼版本的兼容风险。只有在明确理由下（如某个库有安全漏洞必须升）才覆盖其中某个版本——覆盖方式是在自己的 dependencyManagement 里重新声明那个库的版本（它优先于导入的 BOM）。

五、和插件管理不要混淆（易错）

一个高频坑：Maven 插件属于构建过程，不属于应用依赖——所以它们的版本不归 dependencyManagement 管：

应用依赖（jar 库）→ 用 dependencyManagement 管版本、dependencies 里启用。
插件（compiler、Surefire、Failsafe、Jar 插件等）→ 用 pluginManagement 管版本、plugins 里启用。

把「插件版本没生效」当成「依赖问题」去查 dependency:tree，会浪费很多时间。记住这条对应关系：dependencies↔dependencyManagement，plugins↔pluginManagement。

六、多模块工程的推荐结构

顶层父 POM：统一 Java 版本、编码、依赖版本（dependencyManagement/BOM）、插件版本（pluginManagement）、仓库策略。
业务模块：只声明自己实际使用的依赖，不写版本（由父 POM 补齐）。

反模式：在父 POM 的 dependencies（注意不是 dependencyManagement）里塞一堆依赖，让所有子模块都继承——这会让模块边界模糊、增大打包体积、加剧冲突。正确做法是父 POM 只在 dependencyManagement 管版本，具体依赖由需要的子模块自己声明。

七、面试判断题

两个经典判断题，记牢结论：

「dependencyManagement 会不会引入依赖？」→ 不会（只管版本，要 dependencies 才真正引入）。
「导入 BOM 会不会自动把所有库加进项目？」→ 不会（BOM 也只是管理版本，真正用哪些库仍要在 dependencies 声明）。

它们都是版本管理工具，真正让依赖进入项目的只有 dependencies。

八、effective POM 与版本仲裁怎么排查

Maven 真正执行的不是单个源码 POM，而是父 POM、当前 POM、导入 BOM、Profile 与默认模型合并后的 effective POM。依赖图随后还要处理传递依赖、scope、optional、exclusion 和版本冲突，因此“源码里写了什么”不一定等于“最终 classpath 里有什么”。

假设模块同时引入 A 和 B，A 传递依赖 lib:1.0，B 传递依赖 lib:2.0。没有管理项时 Maven 通常按“路径最近者优先”，深度相同再受声明顺序影响；若当前工程的 dependencyManagement 明确管理 lib:3.0，相关传递依赖会按该管理版本统一为 3.0，但前提仍是 A 或 B 真正把 lib 带入依赖图。

app
├─ A ─ lib:1.0
└─ B ─ lib:2.0

dependencyManagement: lib:3.0
最终依赖图：lib:3.0（仍由 A/B 引入，管理区只改版本）

工具或视图	回答的问题	常见用途
`mvn help:effective-pom`	合并后的管理项和插件配置是什么	查父 POM、BOM、Profile 最终结果
`mvn dependency:tree`	哪条路径真正引入了依赖	查传递来源、版本冲突与 omitted 节点
`mvn dependency:help` 等插件帮助	目标和参数如何使用	避免凭记忆拼命令
构建产物或运行 classpath	最终装进或加载了什么	验证打包插件、scope 与部署差异

dependencyManagement 也能提供 scope、exclusions 等依赖声明默认信息，但工程中最常见的用途仍是集中版本。它不能替代依赖树分析：同坐标依赖是否被 optional 截断、被 exclusion 排除或只在 test scope 出现，都需要沿真实路径判断。

排障钩子：先用 effective POM 看“版本规则”，再用 dependency tree 看“引入路径”，最后看构建产物确认“实际交付”；三层证据不要混用。

九、常见误区与追问

误区：父 POM 写了 dependencyManagement，子模块就自动有这个依赖。 它只管理版本，子模块仍要在 dependencies 中声明才会进入 classpath。
误区：导入 BOM 会把 BOM 中所有 jar 都打进项目。 BOM 是版本清单，只在你真正声明某个依赖时提供版本。
误区：插件版本也归 dependencyManagement 管。 Maven 插件要用 pluginManagement 管版本，和应用依赖不是一套配置。
追问：为什么多模块推荐父 POM 管版本、子模块声明依赖？ 这样既统一版本，又保持模块依赖边界清晰，不会全模块继承无用依赖。
追问：覆盖 BOM 中单个版本要怎么做？ 在自己的 dependencyManagement 里重新声明该依赖版本，让本地管理项优先。
追问：BOM 为什么能降低兼容风险？ 维护者给出一组经过组合测试的版本，避免团队手工拼凑互不兼容的组件版本。

十、加强记忆

dependencies 管「有没有（真正引入依赖、进 classpath）」，dependencyManagement 管「用哪个版本（只登记版本/scope，不引入，子模块要在 dependencies 声明才生效、可省 version）」，BOM 管「一组相关库最好一起用哪些版本」（packaging=pom 的版本清单，用 type=pom + scope=import 导入 dependencyManagement，如 Spring Boot BOM，给出经过兼容测试的一套版本，降低手工拼版本风险，可按需覆盖单个版本）。插件版本归 pluginManagement，不归 dependencyManagement（dependencies↔dependencyManagement、plugins↔pluginManagement）。多模块推荐：父 POM 管版本、子模块显式声明依赖，别在父 POM 的 dependencies 塞一堆让全模块继承。判断题：dependencyManagement 和 BOM 都不会自动引入依赖，只有 dependencies 会。

简化版

详细版