如果你无论如何都有一个parent-pom，那么在我看来，使用<dependencyManagement>只是为了控制版本(可能还有范围)是一种浪费空间的行为，而且会让初级开发人员感到困惑。

无论如何，在某种父-pom文件中，您可能会有版本的属性。为什么不直接在子pom中使用这个属性呢?这样，您仍然可以为所有子项目一次更新属性中的版本(在父-pom内)。这与<dependencyManagement>具有相同的效果，只是没有<dependencyManagement>。

在我看来，<dependencyManagement>应该用于“真正的”依赖项管理，比如排除等。

在我看来，还有一件事没有被充分强调，那就是不想要的继承。

下面是一个增量的例子:

我在父母的遗言中声明:

<dependencies>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>19.0</version>
        </dependency>
</dependencies>

繁荣!我把它放在我的子A、子B和子C模块中:

由子poms继承的隐式 一个单独的地方来管理 不需要在child pooms中重新声明任何内容 如果我想，我仍然可以在子B中重新调用和覆盖到18.0版本。

但是，如果我最终在Child C中不需要番石榴，在未来的Child D和Child E模块中也不需要番石榴呢?

他们仍然会继承它，这是不希望的! 这就像Java的God Object代码一样，从类中继承了一些有用的部分，同时也继承了大量不需要的东西。

这就是<dependencyManagement>发挥作用的地方。当你把它添加到你的父pom，你所有的子模块停止看到它。因此，你被迫进入每个单独的模块，确实需要它，并再次声明它(子A和子B，但没有版本)。

显然，您不会为Child C这样做，因此您的模块仍然是精简的。

就像你说的;dependencyManagement用于将所有依赖关系信息拉入一个公共POM文件，从而简化子POM文件中的引用。

当您有多个不想在多个子项目下重新输入的属性时，它就变得非常有用。

最后，dependencyManagement可用于定义工件的标准版本，以便在多个项目中使用。

有几个答案概述了maven的< dependencies >和<dependencyManagement>标记之间的区别。

但是，下面简要阐述了几点:

<dependencyManagement> allows to consolidate all dependencies (used at child pom level) used across different modules -- clarity, central dependency version management <dependencyManagement> allows to easily upgrade/downgrade dependencies based on need, in other scenario this needs to be exercised at every child pom level -- consistency dependencies provided in <dependencies> tag is always imported, while dependencies provided at <dependencyManagement> in parent pom will be imported only if child pom has respective entry in its <dependencies> tag.

两者之间的区别最好体现在Maven网站文档中提供的dependencyManagement元素的必要且充分的定义中:

dependencyManagement

从此继承的项目的默认依赖项信息。此部分中的依赖项不会立即解析。相反，当从这个POM派生的POM声明了一个由匹配的groupId和artifactId描述的依赖项时，如果这个节中的版本和其他值尚未指定，则将用于该依赖项。” [https://maven.apache.org/ref/3.6.1/maven-model/maven.html]

你可以在另一页阅读更多信息:

“. .匹配依赖引用到依赖管理节的最小信息集实际上是{groupId, artifactId, type, classifier}。在许多情况下，这些依赖关系将引用不带分类器的jar工件。这允许我们将标识集简写为{groupId, artifactId}，因为类型字段的默认值是jar，默认分类器是null。[https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html]

Thus, all the sub-elements (scope, exclusions etc.,) of a dependency element--other than groupId, artifactId, type, classifier, not just version--are available for lockdown/default at the point (and thus inherited from there onward) you specify the dependency within a dependencyElement. If you’d specified a dependency with the type and classifier sub-elements (see the first-cited webpage to check all sub-elements) as not jar and not null respectively, you’d need {groupId, artifactId, classifier, type} to reference (resolve) that dependency at any point in an inheritance originating from the dependencyManagement element. Else, {groupId, artifactId} would suffice if you do not intend to override the defaults for classifier and type (jar and null respectively). So default is a good keyword in that definition; any sub-element(s) (other than groupId, artifactId, classifier and type, of course) explicitly assigned value(s) at the point you reference a dependency override the defaults in the dependencyManagement element.

因此，在dependencyManagement之外的任何依赖元素，无论是作为某个dependencyManagement元素的引用，还是作为独立的依赖元素，都将立即被解析(即安装到本地存储库并可用于类路径)。

我在这个问题上迟到了，但我认为它值得一个比公认的回答更清晰的回答(公认的回答是正确的，但没有强调实际重要的部分，这需要您自己推断)。

在父POM中，<dependencies>和<dependencyManagement>之间的主要区别是:

Artifacts specified in the <dependencies> section will ALWAYS be included as a dependency of the child module(s). Artifacts specified in the <dependencyManagement> section, will only be included in the child module if they were also specified in the <dependencies> section of the child module itself. Why is it good you ask? Because you specify the version and/or scope in the parent, and you can leave them out when specifying the dependencies in the child POM. This can help you use unified versions for dependencies for child modules, without specifying the version in each child module.