当某个库（如 dep-b）既被项目显式声明为直接依赖，又被另一直接依赖（如 dep-a）作为传递依赖引入时，应优先信任上游依赖所锁定的版本组合，避免手动覆盖——最稳妥的做法是移除该库的显式声明，完全依赖 maven 的依赖调解机制自动解析。
当某个库（如 dep-b）既被项目显式声明为直接依赖，又被另一直接依赖（如 dep-a）作为传递依赖引入时，应优先信任上游依赖所锁定的版本组合，避免手动覆盖——最稳妥的做法是移除该库的显式声明，完全依赖 maven 的依赖调解机制自动解析。
在 Maven 依赖管理中，“直接依赖即权威”是一种常见误解。实际上，Maven 的依赖调解（Dependency Mediation）规则明确指出：当同一坐标（groupId:artifactId）以不同版本出现在依赖图中时，Maven 默认采用‘最近路径优先’（nearest definition wins）策略。这意味着，若 dep-a:x 声明了 dep-b:y 作为其 <dependency></dependency>，而你的 pom.xml 又显式声明了 dep-b:z（z ≠ y），则最终生效的版本取决于二者在依赖树中的深度——但更关键的是：这种显式覆盖破坏了 dep-a 经验证的兼容性契约。
dep-a 在发布版本 x 时，其构建、测试与集成均基于 dep-b:y 完成。强行升级至 dep-b:z（尤其当 dep-b 迭代激进、dep-a 更新滞后时），极易引发 NoSuchMethodError、IncompatibleClassChangeError 或静默行为变更等运行时问题——这类问题往往难以复现、调试成本极高。
✅ 正确做法：不声明 dep-b 为直接依赖，仅保留 dep-a
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
<!-- pom.xml -->
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>dep-a</artifactId>
<version>1.5.0</version>
</dependency>
<!-- ✅ 移除以下显式声明 -->
<!--
<dependency>
<groupId>com.example</groupId>
<artifactId>dep-b</artifactId>
<version>2.3.0</version>
</dependency>
-->
</dependencies>此时，Maven 将自动解析 dep-a:1.5.0 所声明的 dep-b:y（例如 2.1.0），并确保整个 classpath 中仅存在该版本。可通过以下命令验证：
mvn dependency:tree -Dincludes=com.example:dep-b
⚠️ 注意事项：
-
禁止使用
<exclusions></exclusions>+ 显式重引入：例如在dep-a中排除dep-b后再单独引入新版——这等同于主动破坏兼容性基线； -
慎用
<dependencymanagement></dependencymanagement>强制版本：除非你已全面验证dep-a:x与dep-b:z的兼容性（包括所有间接调用路径），否则不应通过<dependencymanagement></dependencymanagement>全局锁定dep-b:z； -
自动化工具需适配此策略：将 Dependabot 配置为仅监控
dep-a的更新（而非dep-b），或设置ignore规则跳过dep-b的 PR；也可利用 Maven Versions Plugin 的versions:display-dependency-updates检查dep-a升级后是否自然带入更新版dep-b； -
例外场景：仅当
dep-b提供了独立于dep-a的核心能力（如通用工具类、SPI 实现），且项目代码直接强耦合其 API 时，才考虑显式声明——此时应严格遵循dep-a所兼容的dep-b版本范围（如<version>[2.1.0,2.4.0)</version>），并通过mvn verify集成测试保障。
归根结底，Maven 的设计哲学是“约定优于配置”。尊重上游依赖的版本声明，不仅是减少技术债的务实选择，更是构建可重复、可预测构建环境的基石。
