本文探讨了为何不能直接将“胖jar”（fat jar）作为普通依赖加载，以及在spring boot、tomcat等环境中安全引入含内嵌libs目录的外部jar的规范做法——推荐剥离依赖、分层管理，而非解压加载。
在Java生态中，常遇到一类结构特殊的外部JAR包：其内部不仅包含编译后的类文件，还嵌套了一个libs/目录，内含d1.jar、d2.jar等依赖项（即所谓“自包含式JAR”）。这类JAR本质上是可执行胖JAR（executable fat jar），设计初衷是独立运行（如java -jar xxx.jar），而非作为被其他项目引用的库依赖（library dependency）。JVM原生类加载器（包括Spring Boot的LaunchedURLClassLoader和Tomcat的WebappClassLoader）默认不支持递归扫描JAR内的嵌套JAR——这意味着即使你通过-classpath xxx.jar或loader.path=xxx.jar指定该包，其中libs/d1.jar中的类仍无法被自动发现和加载。
❌ 错误做法：强行解压并拼接类路径
虽然技术上可行（例如用jar -xvf xxx.jar解压出libs/目录，再将d1.jar、d2.jar逐一加入-classpath），但该方式存在严重缺陷：
- 破坏依赖隔离性，易引发版本冲突；
- 丧失构建可重现性（需人工维护解压步骤）；
- 违反JVM类加载契约，部分容器（如Tomcat 9+）会主动拒绝加载嵌套JAR路径；
- Spring Boot的loader.path仅支持顶层JAR/WAR/ZIP，不解析内部嵌套结构。
✅ 推荐方案：回归标准依赖管理
应将xxx.jar重构为纯净库JAR（即仅含/com/xxx/类文件，不含/libs目录），并将d1.jar、d2.jar作为独立依赖引入：
方式1：从Maven中央仓库声明（首选）
<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>方式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>⚠️ 注意：system范围依赖不会被打包进Spring Boot Fat Jar（需配合maven-dependency-plugin手动拷贝），且在多模块项目中需确保路径一致性。
方式3：Spring Boot中扩展类路径（生产慎用）
若必须动态加载本地JAR，可通过loader.path指向解压后的独立JAR目录（非原始fat JAR）：
立即学习“Java免费学习笔记（深入）”；
java -Dloader.path=./external-libs/ -jar app.jar
其中./external-libs/需包含已提取的d1.jar、d2.jar等，而非xxx.jar本身。
总结
真正的解决方案不在于“如何让JVM读取嵌套JAR”，而在于遵循Java依赖管理的最佳实践：将胖JAR拆分为清晰的坐标化依赖，交由构建工具（Maven/Gradle）统一解析与传递。这不仅保障运行时稳定性，也使依赖关系可视化、可审计、可升级。对于遗留胖JAR，建议使用jar -tf xxx.jar分析内容，结合mvn deploy:deploy-file将其发布至私有仓库，完成标准化转型。
