当某个 JAR（如 Tar.jar）因 被上游依赖（如 A1→A2）主动排除后，即使其他路径（如 B1→B2→B3→Tar.jar）仍声明了该依赖，Maven 默认也不会自动“补回”——需显式声明或通过 dependencyManagement 恢复。

当某个 jar（如 tar.jar）因 `` 被上游依赖（如 a1→a2）主动排除后，即使其他路径（如 b1→b2→b3→tar.jar）仍声明了该依赖，maven 默认也不会自动“补回”——需显式声明或通过 dependencymanagement 恢复。

在 Maven 的依赖解析机制中， 是全局生效且不可逆的：一旦 A1 在引入 A2 时排除了 Tar，则无论项目中是否存在其他更长路径（如 B1 → B2 → B3 → Tar.jar），只要该路径未在当前 pom.xml 中被显式“激活”，Maven 就不会将 Tar.jar 加入最终依赖树。这是由 Maven 的最近依赖优先（nearest definition wins）与排除传递性共同决定的——排除操作会切断整个传递链，而非仅作用于某一分支。

✅ 正确解决方案有两种，推荐按优先级选择：

方案一：直接声明依赖（最清晰、最可靠）

在你的项目根 pom.xml 的 中显式添加 Tar.jar，无需关心其来源路径：

<dependency><groupid>xxx</groupid><artifactid>Tar</artifactid><version>1.2.3</version><!-- 请替换为实际版本 --></dependency>

⚠️ 注意：

• 版本号必须明确指定（Maven 不会自动推断被排除依赖的版本）；
• 若多个模块依赖不同版本的 Tar，建议统一升级并在此处锁定版本，避免冲突。

方案二：使用 统一管理（适合多模块项目）

若项目含多个子模块，或希望集中控制 Tar 的版本与可见性，可在父 POM 的 中声明：

<dependencymanagement><dependencies><dependency><groupid>xxx</groupid><artifactid>Tar</artifactid><version>1.2.3</version><scope>compile</scope></dependency></dependencies></dependencymanagement>

随后，在需要 Tar.jar 的任意子模块 pom.xml 中，仅需不带 version 的简写依赖即可触发管理项生效：

<dependency><groupid>xxx</groupid><artifactid>Tar</artifactid></dependency>

? 补充说明：

• 本身不引入依赖，仅提供版本/范围/排除等模板；只有在子模块中实际声明 时才会生效；
• 此方案能有效避免重复声明、提升可维护性，特别适用于企业级多模块工程；
• 不要尝试用 true 或调整 （如 provided）来“绕过”排除——它们无法恢复已被切断的传递依赖。

? 总结：Maven 的依赖排除是单向阻断行为，没有隐式“回溯补全”机制。要确保 Tar.jar 可用，必须在当前构建单元（即你的项目 POM）中主动引入它——要么直写 ，要么通过 + 子模块引用协同实现。这是符合 Maven 设计哲学的确定性做法，也是解决此类问题唯一健壮、可预测的方式。