Maven依赖管理：显式声明版本还是排除传递依赖？

方案1：显式声明传递依赖版本的额外潜在问题 #

• 依赖版本不匹配风险：如果initech-library升级后，其内部依赖的printer-tools/penny-pinching/tps-reports版本发生变更，但你没同步更新显式声明的版本，会导致项目强制使用旧版本，和initech-library的新版本出现兼容性冲突，比如方法签名不匹配、类加载异常等。
• 过度锁定引发的连锁冲突：显式声明的版本会强制覆盖所有其他依赖的传递版本。比如如果后续引入第三个依赖new-utils:1.5，它需要printer-tools:2.0，但你显式声明了1.0.2，就会强制用旧版本，导致new-utils功能失效。
• 依赖关系混淆：显式声明后，pom.xml里的直接依赖会混入原本的传递依赖，新人或者后续排查问题时，很难区分哪些是项目真正需要的直接依赖，哪些是为了锁版本加的，用mvn dependency:tree排查冲突时也会更难理清依赖链。
• pom文件臃肿冗余：随着项目依赖增多，为了锁版本添加的显式声明会越来越多，让pom.xml变得冗长，增加维护成本，也容易出现漏更、错更的情况。

方案2：排除传递依赖的额外潜在问题 #

• 依赖缺失或功能断裂：如果other-tools的某些功能实际依赖它传递的旧版本tps-reports，你排除后，这些功能会因为找不到对应的类或方法而报错，而且这类问题很多时候编译期发现不了，要到运行时才暴露。
• 排除规则的覆盖盲区：如果other-tools是多模块依赖，你只在根模块排除tps-reports，可能无法覆盖它的子模块传递的依赖；或者如果后续有其他依赖间接引入other-tools，之前的排除规则不会生效，旧版本tps-reports还是会被拉进来。
• 隐藏的兼容性冲突：你排除other-tools的tps-reports后，项目会用initech-library的3.4.9，但other-tools可能和这个新版本存在兼容性问题——比如other-tools调用了tps-reports旧版本的私有方法，或者依赖旧版本的配置格式，这些问题在编译阶段很难检测到，上线后才会出问题。
• 排除规则的残留冗余：如果后续other-tools升级后不再依赖旧版本tps-reports，但你没及时移除排除规则，这些无效的配置会留在pom.xml里，增加代码混乱度，也会给后续维护者造成误解。

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