当某个 JAR（如 Tar.jar）因 <exclusion> 被上游依赖（如 A1→A2）主动排除后，即使其他路径（如 B1→B2→B3→Tar.jar）仍声明了该依赖，Maven 默认也不会自动“补回”——需显式声明或通过 dependencyManagement 恢复。
当某个 jar（如 tar.jar）因 `
在 Maven 的依赖解析机制中，<exclusion> 是全局生效且不可逆的：一旦 A1 在引入 A2 时排除了 Tar，则无论项目中是否存在其他更长路径（如 B1 → B2 → B3 → Tar.jar），只要该路径未在当前 pom.xml 中被显式“激活”，Maven 就不会将 Tar.jar 加入最终依赖树。这是由 Maven 的最近依赖优先（nearest definition wins）与排除传递性共同决定的——排除操作会切断整个传递链，而非仅作用于某一分支。
✅ 正确解决方案有两种，推荐按优先级选择：
方案一：直接声明依赖（最清晰、最可靠）
在你的项目根 pom.xml 的 <dependencies> 中显式添加 Tar.jar，无需关心其来源路径：
<dependency>
<groupId>xxx</groupId>
<artifactId>Tar</artifactId>
<version>1.2.3</version> <!-- 请替换为实际版本 -->
</dependency>⚠️ 注意：
- 版本号必须明确指定（Maven 不会自动推断被排除依赖的版本）；
- 若多个模块依赖不同版本的 Tar，建议统一升级并在此处锁定版本，避免冲突。
方案二：使用 <dependencyManagement> 统一管理（适合多模块项目）
若项目含多个子模块，或希望集中控制 Tar 的版本与可见性，可在父 POM 的 <dependencyManagement> 中声明：
<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>? 补充说明：
- <dependencyManagement> 本身不引入依赖，仅提供版本/范围/排除等模板；只有在子模块中实际声明 <dependency> 时才会生效；
- 此方案能有效避免重复声明、提升可维护性，特别适用于企业级多模块工程；
- 不要尝试用 <optional>true</optional> 或调整 <scope>（如 provided）来“绕过”排除——它们无法恢复已被切断的传递依赖。
? 总结：Maven 的依赖排除是单向阻断行为，没有隐式“回溯补全”机制。要确保 Tar.jar 可用，必须在当前构建单元（即你的项目 POM）中主动引入它——要么直写 <dependency>，要么通过 <dependencyManagement> + 子模块引用协同实现。这是符合 Maven 设计哲学的确定性做法，也是解决此类问题唯一健壮、可预测的方式。
