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

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

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

对不起，我迟到了。

让我尝试使用mvn dependency:tree命令来解释两者的区别

考虑下面的例子

父母POM -我的项目

<modules>
    <module>app</module>
    <module>data</module>
</modules>

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

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
            <version>3.9</version>
        </dependency>
    </dependencies>
</dependencyManagement>

子POM -数据模块

<dependencies>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
    </dependency>
</dependencies>

子POM -应用程序模块(没有额外的依赖项，因此将依赖项留空)

 <dependencies>
</dependencies>

在运行mvn dependency:tree命令时，我们得到如下结果

Scanning for projects...
------------------------------------------------------------------------
Reactor Build Order:

MyProject
app
data

------------------------------------------------------------------------
Building MyProject 1.0-SNAPSHOT
------------------------------------------------------------------------

--- maven-dependency-plugin:2.8:tree (default-cli) @ MyProject ---
com.iamvickyav:MyProject:pom:1.0-SNAPSHOT
\- com.google.guava:guava:jar:19.0:compile

------------------------------------------------------------------------
Building app 1.0-SNAPSHOT
------------------------------------------------------------------------

--- maven-dependency-plugin:2.8:tree (default-cli) @ app ---
com.iamvickyav:app:jar:1.0-SNAPSHOT
\- com.google.guava:guava:jar:19.0:compile

------------------------------------------------------------------------
Building data 1.0-SNAPSHOT
------------------------------------------------------------------------

--- maven-dependency-plugin:2.8:tree (default-cli) @ data ---
com.iamvickyav:data:jar:1.0-SNAPSHOT
+- org.apache.commons:commons-lang3:jar:3.9:compile
\- com.google.guava:guava:jar:19.0:compile

谷歌guava在每个模块(包括父模块)中都被列为依赖项，而apache commons仅在数据模块中被列为依赖项(甚至不在父模块中)

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

下面是一个增量的例子:

我在父母的遗言中声明:

<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这样做，因此您的模块仍然是精简的。

有几个答案概述了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.

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

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