本文探讨了为何不能直接将“胖jar”（fat jar）作为外部库加载，以及在spring boot、tomcat等环境中安全引入含内嵌依赖（如`libs/d1.jar`）的jar的规范做法。核心结论是：应拆分胖jar，将其转为标准依赖，并通过maven/gradle或`loader.path`显式管理各依赖项。
在Java生态中，常遇到一类结构特殊的外部JAR包：其内部不仅包含编译后的类文件，还嵌套了一个libs/目录，存放多个依赖JAR（如d1.jar、d2.jar）。这类JAR本质上是一个可执行胖JAR（fat JAR）——设计初衷是独立运行（如java -jar xxx.jar），而非作为被其他项目引用的库。JVM和主流容器（Spring Boot、Tomcat）的类加载机制默认不支持递归扫描JAR内的嵌套JAR。这意味着即使你通过-classpath xxx.jar或Spring Boot的--loader.path=xxx.jar启动，JVM只会加载xxx.jar顶层的class，而忽略libs/下的所有依赖，导致ClassNotFoundException。
❌ 错误做法：尝试直接加载胖JAR
有人试图解压胖JAR再批量添加路径：
# 解压并手动加入类路径（不推荐！） unzip xxx.jar -d temp/ java -cp "temp/:temp/libs/*" com.example.Main
这种方式破坏构建可重现性，易引发版本冲突、路径污染，且无法被Maven/Gradle依赖解析器识别，违背Java模块化最佳实践。
✅ 推荐方案：标准化依赖管理
方案1：发布为独立Maven依赖（首选）
将xxx.jar重构为普通库JAR（不含libs/目录），并将d1.jar、d2.jar分别发布至私有或公共Maven仓库（如Nexus、Maven Central）。在项目中声明清晰依赖：
立即学习“Java免费学习笔记（深入）”；
com.tonny.xxx xxx-core 1.0.0 com.tonny.xxx d1 4.1 com.tonny.xxx d2 2.3
方案2：本地系统依赖（仅限开发/离线场景）
若无法上传仓库，可使用Maven system scope（注意：Spring Boot Maven Plugin默认跳过system依赖打包，需额外配置）：
com.tonny.xxx d1 4.1 system ${project.basedir}/lib/d1.jar
⚠️ 注意事项：
- system依赖不会被传递，下游项目需重复声明；
- 构建时需确保lib/目录存在且路径正确；
- 生产环境强烈建议改用私有仓库替代。
方案3：Spring Boot专用 —— loader.path + 显式依赖
对已有的胖JAR，可提取其libs/内容到独立目录，再通过loader.path统一加载：
# 提取依赖（一次性操作） mkdir -p external-deps unzip xxx.jar 'libs/*' -d external-deps/ # 启动时指定全部JAR路径 java -Dloader.path="external-deps/libs/" -jar myapp.jar
此时需确保myapp.jar的MANIFEST.MF中包含org.springframework.boot.loader.JarLauncher，且Spring Boot版本 ≥ 2.3（支持多级loader.path）。
总结
胖JAR ≠ 库JAR。任何试图绕过标准依赖管理机制（Maven/Gradle）、依赖运行时动态解压或路径拼接的做法，都会牺牲可维护性、可测试性和环境一致性。正确的路径是：解耦胖JAR，回归语义化依赖声明——让每个JAR各司其职，由构建工具统一解析、校验与隔离。
