当某个传递依赖（如 Tar.jar）因上游模块使用 被意外移除时，可通过显式声明该依赖或利用 统一恢复其版本与可见性，无需修改原始模块 POM。
当某个传递依赖（如 tar.jar）因上游模块使用 `
` 被意外移除时，可通过显式声明该依赖或利用 `` 统一恢复其版本与可见性，无需修改原始模块 pom。
在 Maven 项目中， 用于切断特定传递依赖的继承链，但有时会导致下游模块（如依赖 B3 → Tar.jar）因依赖路径更深而无法“穿透”已被截断的 A1 → A2 → Tar.jar 链路，最终造成 Tar.jar 在最终 classpath 中缺失——即使 B3 明确需要它。
根本原因
：Maven 的依赖解析遵循“第一声明优先”和“最近定义优先”原则。一旦某条依赖路径（如 A1 → A2 → Tar.jar）被显式排除，Maven 不会自动尝试从其他更长路径（如 B1 → B2 → B3 → Tar.jar）补全该 JAR；它只保留未被排除、且能成功解析的依赖项。
✅
推荐解决方案（两种，按场景选择）
：
方案一：显式声明依赖（最直接、推荐初学者使用）
在你项目的 pom.xml 的 中直接添加 Tar.jar，Maven 会将其提升为直接依赖，确保其必然出现在 classpath 中：
✅ 优点：语义清晰、行为确定、调试友好；
⚠️ 注意：需手动指定版本，建议通过 mvn dependency:tree -Dverbose 查看 B3 所需的 Tar.jar 版本，避免冲突。
方案二：使用 统一管理（适合多模块/团队项目）
若项目含多个子模块，或希望集中控制 Tar.jar 的版本与作用域，可在根 POM 或当前 POM 的 中声明：
随后，在任意子模块（包括当前模块）中，仅需声明无版本的依赖即可激活它：
✅ 优点：版本统一、避免重复声明、便于升级维护；
? 提示： 本身不引入依赖，必须配合 使用才生效。
❌
不推荐的做法
：
修改 A1 或 B3 的 POM（你无权或不应改动第三方/上游模块）；
尝试用 relocation 或 optional=true 曲线救国——这无法解决已排除依赖的可见性问题。
验证是否生效
：
执行以下命令检查 Tar.jar 是否已正确出现在最终依赖树中：
应看到类似 +- xxx:Tar:jar:1.2.3:compile 的输出，且不在 (omitted for duplicate) 或 (omitted for conflict) 状态下。
总结：Maven 不支持“自动回溯恢复被排除的传递依赖”。主动声明（）或受控声明（ + ）是标准、可靠且符合 Maven 设计哲学的解法——既尊重依赖隔离原则，又保障运行时完整性。
xxx
Tar
1.2.3
xxx
Tar
1.2.3
xxx
Tar
mvn dependency:tree | grep -i "Tar"