本文详解为何不能直接将含 libs/ 目录的“胖 jar”作为普通依赖加载，以及在 spring boot、tomcat 等环境中安全引入外部库的标准化实践方案。
在 Java 生态中，常遇到一类结构特殊的外部 JAR：其内部不仅包含编译后的类（如 com/example/MyUtil.class），还嵌套了一个 libs/ 文件夹，内含 d1.jar、d2.jar 等依赖项——这类归档本质上是可执行的“胖 JAR”（Fat JAR），设计初衷是独立运行（如 java -jar xxx.jar），而非作为被其他应用引用的库依赖。
❌ 为什么不能直接加载含 libs 的 JAR？
Java 原生类加载器（包括 URLClassLoader、Spring Boot 的 LaunchedURLClassLoader 或 Tomcat 的 WebappClassLoader）不会自动扫描并加载 JAR 内部的嵌套 JAR。例如：
# 错误示例：以下命令无法让 JVM 自动识别 xxx.jar/libs/d1.jar 中的类 java -cp "xxx.jar" com.example.Main
即使通过 -Dloader.path=xxx.jar（Spring Boot）或 CLASSPATH=xxx.jar 启动，JVM 仅将 xxx.jar 本身加入类路径，而 libs/ 下的 JAR 仍处于“不可见”状态。强行解压后手动拼接 classpath（如 unzip xxx.jar -d tmp && java -cp "tmp:tmp/libs/*" ...）虽技术可行，但违背工程规范：缺乏版本控制、破坏可重现性、难以审计依赖、且易引发类冲突或加载顺序问题。
✅ 推荐方案：拆分依赖，按标准方式管理
正确的做法是解耦“发布包”与“依赖库”，将 xxx.jar 重构为纯功能 JAR（不含 libs/），并将 d1.jar、d2.jar 等作为独立依赖，通过以下任一方式引入：
方式 1：发布至私有 Maven 仓库（推荐）
将 d1、d2 等构件部署到 Nexus/Artifactory，然后在项目中声明标准依赖：
<!-- Maven pom.xml --> <dependency><groupid>com.tonny.xxx</groupid><artifactid>d1</artifactid><version>4.1</version></dependency><dependency><groupid>com.tonny.xxx</groupid><artifactid>d2</artifactid><version>2.7</version></dependency>
Spring Boot 会自动将其纳入 BOOT-INF/lib/；Tomcat 应用则可通过 maven-war-plugin 打包至 WEB-INF/lib/。
方式 2：本地系统依赖（仅限开发/离线场景）
若无法接入仓库，可使用
<dependency><groupid>com.tonny.xxx</groupid><artifactid>d1</artifactid><version>4.1</version><scope>system</scope><systempath>${project.basedir}/lib/d1.jar</systempath></dependency>
⚠️ 注意事项： systemPath 必须为绝对路径或基于 ${project.basedir} 的相对路径； 此方式不参与依赖传递，其他模块无法继承该依赖； 严禁在 CI/CD 流水线中使用，会导致构建环境不一致。
方式 3：Spring Boot 特定扩展（高级场景）
对 Spring Boot 应用，若必须动态加载外部 JAR 及其依赖，可自定义 URLClassLoader 并递归解析嵌套 JAR（需自行实现 JarFile 解析逻辑），但强烈建议仅用于插件化架构等特殊需求，而非常规依赖管理。
总结
- “胖 JAR” ≠ 可复用库：其 libs/ 结构是运行时封装策略，非依赖管理契约；
- 坚持依赖显式化：每个 JAR 应有唯一坐标（GAV），由构建工具统一解析；
- 优先选择远程仓库，次选本地 system 依赖，避免手动解压 + classpath 拼接；
- 在微服务或模块化架构中，应推动上游将 xxx.jar 发布为合规 Maven 构件，从根本上解决问题。
遵循以上原则，既能保障依赖清晰可溯，又能兼容 Spring Boot、Tomcat、传统 Java SE 等各类运行环境。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
