本文详解如何在 Maven 构建 WAR 包时仅保留直接声明的依赖，避免 batik-all 等“胖 JAR”引入大量冗余传递依赖，通过理解依赖类型、合理选用 artifact、配合 与插件配置，实现对 WEB-INF/lib 目录内容的精确管控。
本文详解如何在 maven 构建 war 包时**仅保留直接声明的依赖**，避免 `batik-all` 等“胖 jar”引入大量冗余传递依赖，通过理解依赖类型、合理选用 artifact、配合 `
在将传统 Ant 项目迁移到 Maven 的过程中，一个常见但易被忽视的关键挑战是：如何确保最终生成的 WAR 文件中 WEB-INF/lib/ 目录仅包含显式声明的直接依赖，而非自动拉取的数十个传递依赖？尤其当引入如 batik-all 这类预打包的“胖 POM”（fat POM）或“胖 JAR”时，问题尤为突出——它本身已将所有子模块（如 batik-svggen、batik-dom、xml-apis 等）以 <type>pom</type> 方式聚合声明，导致 Maven 默认将其全部解析并打入 WAR。
? 根本原因：batik-all 不是普通依赖，而是“依赖聚合器”
您遇到的问题并非配置错误，而是对 batik-all 的语义理解偏差：
<dependency><groupid>org.apache.xmlgraphics</groupid><artifactid>batik-all</artifactid><version>1.16</version><type>pom</type><!-- 关键！这不是JAR，而是一个POM聚合体 --></dependency>
该依赖的 <type>pom</type> 表明它本身不提供任何 class 文件，而是一个 依赖管理清单（BOM-like） ——其 batik-all-1.16.pom 文件中通过 <dependency></dependency> 列出了约 30 个子模块。Maven 会递归解析这些子依赖，并全部纳入构建范围。此时使用 <exclusions></exclusions> 排除 *:* 是无效的，因为 <exclusion></exclusion> 只能排除 已被声明的直接子依赖，而 batik-all 的 POM 中每个子项都是独立 <dependency></dependency>，通配符 * 在 Maven 中不支持（会静默忽略），且无法批量排除未显式写出的坐标。
✅ 正确解法不是“剔除”，而是“替换”：
弃用
batik-all，改用按需声明的细粒度模块
例如，若项目仅需 SVG 渲染能力，可只引入核心组件：
<dependencies><!-- 替代 batik-all：仅引入实际需要的模块 --><dependency><groupid>org.apache.xmlgraphics</groupid><artifactid>batik-svggen</artifactid><version>1.16</version></dependency><dependency><groupid>org.apache.xmlgraphics</groupid><artifactid>batik-dom</artifactid><version>1.16</version></dependency><dependency><groupid>org.apache.xmlgraphics</groupid><artifactid>batik-parser</artifactid><version>1.16</version></dependency><!-- 可选：若需 XML 支持 --><dependency><groupid>xml-apis</groupid><artifactid>xml-apis</artifactid><version>2.0.2</version></dependency></dependencies>
这样，Maven 仅解析您明确列出的 3–5 个 JAR，彻底规避“一引全拉”的问题。
⚙️ 辅助控制：WAR 插件级精细过滤（按需启用）
若您仍需保留 batik-all（如历史兼容性要求），可通过 maven-war-plugin 的 <packagingexcludes></packagingexcludes> 进行运行时裁剪（注意：这是兜底方案，非首选）：
<plugin><groupid>org.apache.maven.plugins</groupid><artifactid>maven-war-plugin</artifactid><version>3.2.2</version><configuration><!-- 排除所有 batik-* 子模块（除 batik-all.jar 本身） --><packagingexcludes>
WEB-INF/lib/batik-*.jar,
WEB-INF/lib/xml-apis*.jar,
WEB-INF/lib/xercesImpl*.jar
</packagingexcludes></configuration></plugin>
⚠️ 注意事项：
-
<packagingexcludes></packagingexcludes>是字符串匹配，非坐标匹配，需准确写出 JAR 文件名； - 它作用于
war:war阶段，不影响编译期依赖解析，仅控制最终归档内容； - 不推荐用于大规模排除（如题中提到的 80+ 项），易出错且难维护。
✅ 最佳实践总结
| 场景 | 推荐策略 | 说明 |
|---|---|---|
| 新项目 / 可重构 | ✅ 拆分胖依赖，按需引入细粒度模块 | 最干净、可追溯、利于版本升级与冲突治理 |
| 强兼容性要求 | ✅ <dependencymanagement></dependencymanagement> 锁定关键版本 + <exclusions></exclusions> 精准排除 |
结合 dependency:tree -Dverbose 定位冲突路径后定向排除 |
| 临时应急 / 遗留系统 | ⚠️ maven-war-plugin 的 packagingExcludes
|
仅限小范围、命名规则明确的排除，避免正则滥用 |
最后提醒：执行 mvn dependency:tree -Dincludes=org.apache.xmlgraphics:batik 可清晰验证当前解析路径；搭配 IDEA 的 Maven → Show Dependencies 视图，能直观识别哪些依赖被“隐式带入”。真正的依赖治理，始于对坐标语义的理解，而非配置技巧的堆砌。
通过本次迁移，您不仅解决了 WAR 打包臃肿问题，更建立起一套可持续演进的依赖契约——每一行 <dependency></dependency> 都应有明确业务意图，而非“以防万一”的盲目叠加。
