使用未声明的Maven传递依赖有哪些弊端？为何属不良实践？

这确实是个挺容易让人困惑的点——毕竟Maven搞传递依赖就是为了帮我们少写重复配置，但直接用没在pom.xml里显式声明的传递依赖，真的是个隐患不小的不良实践，主要原因有这些：

1. 依赖关系完全不透明，维护起来头大 #

当你直接用某个传递来的依赖时，其他看项目的开发者（包括几个月后忘了细节的你自己）扫一眼pom.xml根本不知道这个依赖是哪来的。比如你在代码里用了Guava的工具类，但它是通过spring-core间接带进来的，别人要排查依赖冲突、升级版本的时候，得反复跑mvn dependency:tree去溯源，效率低到离谱。

2. 父依赖变更直接导致项目崩溃 #

假设你依赖的某个核心模块（比如spring-core）在某次升级里移除了对Guava的依赖，或者把版本换成了一个不兼容的旧版，你的项目会突然炸出ClassNotFoundException或者方法不存在的报错。更坑的是，这种问题编译阶段可能查不出来，得等运行时才暴露，排查起来特别费劲。

3. 版本管控存在隐形风险 #

哪怕你在根pom的dependencyManagement里统一管了版本，也架不住意外情况：比如传递依赖的父模块突然改了依赖的groupId/artifactId，或者你的dependencyManagement没覆盖这个版本，一旦父模块升级，你用的传递依赖版本就会跟着变，很可能引入兼容性问题。而显式声明的依赖，版本完全由你说了算，不会被悄悄篡改。

4. 违反了依赖显式性的基本原则 #

Maven的设计思路里，显式声明依赖就是为了让项目的依赖图谱清晰可查。就像写Java代码要显式import类，而不是依赖隐式的类路径一样，显式声明依赖能让项目的依赖关系变成文档的一部分，团队协作时所有人都能快速搞清楚项目依赖了哪些第三方库，避免“暗箱操作”。

5. 构建稳定性大打折扣 #

不同的传递依赖可能会引入同一个库的不同版本，显式声明依赖能让你明确指定要用的版本，避免Maven依赖调解机制（比如“最短路径”或“声明优先”）带来的意外结果。如果依赖是隐式的，你根本没法控制Maven最终选哪个版本，构建结果的不确定性会大大增加。

内容的提问来源于stack exchange，提问作者Ahmed Hammad