exclusions标签用于精准排除指定groupid和artifactid的传递依赖，不处理版本且不拦截漏洞本身；需先排除含漏洞的依赖，再显式引入修复版本，并通过dependency:tree验证唯一性。
Exclusions 标签本身不拦截“恶意漏洞”，它只负责阻止特定传递依赖被自动引入。所谓“恶意漏洞”实际是下游依赖中已知存在安全风险的版本（如 log4j 2.0–2.14.1、commons-collections3 3.1 等）。Maven 的 exclusion 机制是解决这类问题的第一步：先切断漏洞路径，再主动引入修复后的干净版本。
明确要排除的目标依赖坐标
关键不是猜哪个包“有问题”，而是根据漏洞报告（如 CVE 编号或 IDE 提示）锁定 groupId + artifactId。版本号在 <exclusion></exclusion> 中完全不需要写，写了也无效。
- 例如 CVE-2021-44228（Log4j2 远程执行）对应依赖：
org.apache.logging.log4j:log4j-core - IDEA 或
mvn dependency:tree -Dincludes=org.apache.logging.log4j可快速定位它从哪个第三方组件（如spring-boot-starter-web或某个 SDK）传递进来
在父级依赖中声明 exclusion
找到引入该漏洞依赖的直接依赖项，在它的 <dependency></dependency> 块内添加 <exclusions></exclusions>。一个典型结构如下：
<dependency><groupid>com.example.sdk</groupid><artifactid>payment-gateway</artifactid><version>2.4.0</version><exclusions><exclusion><groupid>org.apache.logging.log4j</groupid><artifactid>log4j-core</artifactid></exclusion><exclusion><groupid>org.yaml</groupid><artifactid>snakeyaml</artifactid></exclusion></exclusions></dependency>
注意：<exclusion></exclusion> 必须和实际传递链中的 GAV 完全匹配（groupId 和 artifactId 大小写敏感），但 version 字段留空。
手动引入修复后的新版本
仅排除还不够——项目仍可能因其他路径重新引入旧版。必须在 <dependencies></dependencies> 顶层显式声明安全版本，确保它参与 Maven 的版本仲裁并胜出：
- 查 mvnrepository.com 确认修复版本（如 log4j-core 2.17.2+）
- 添加独立依赖项（无需 exclusion）：
<dependency><groupid>org.apache.logging.log4j</groupid><artifactid>log4j-core</artifactid><version>2.20.0</version></dependency>
- 验证：运行
mvn dependency:tree | grep log4j，确认只有你指定的版本出现，且无 warning 提示版本冲突
批量排除与父子模块协同控制
当多个子模块都通过不同 SDK 引入同一漏洞依赖时，可在父 POM 的 <dependencymanagement></dependencymanagement> 中统一排除，避免重复配置：
<dependencymanagement><dependencies><dependency><groupid>com.example.common</groupid><artifactid>shared-lib</artifactid><version>1.8.0</version><exclusions><exclusion><groupid>javax.xml.bind</groupid><artifactid>jaxb-api</artifactid></exclusion></exclusions></dependency></dependencies></dependencymanagement>
子模块只需声明该依赖（不写 version 和 exclusions），即可继承父级排除规则，保持一致性。
