systemPath依赖不会被打进Spring Boot的fat jar，运行时必报类找不到异常；正确做法是用mvn install安装到本地仓库后按常规依赖引用。
systemPath依赖在Spring Boot里根本不会被打进fat jar
直接说结论：systemPath 方式声明的本地 .jar 包，在 Spring Boot 的 mvn spring-boot:repackage 过程中会被完全忽略——运行时必报 NoClassDefFoundError 或 ClassNotFoundException。
这不是 bug，是设计使然：Spring Boot 的 fat jar 打包逻辑只扫描 compile 和 runtime 范围的常规依赖，而 system 范围依赖被 Maven 明确排除在 classpath assembly 之外。
-
system - IDE（如 IntelliJ）可能误判为可用，但
java -jar app.jar一定失败 - 哪怕加了
true maven-jar-plugin，对 Spring Boot 的 repackage 也无效
正确做法：用 mvn install 把本地 jar 安装到本地仓库
把第三方 .jar 当作普通依赖对待，让它进入 Maven 的坐标体系，才能被 Spring Boot 正常识别和打包。
操作分两步，缺一不可：
- 执行命令安装：
mvn install:install-file -Dfile=/path/to/xxx.jar -DgroupId=com.example -DartifactId=xxx-sdk -Dversion=1.0.0 -Dpackaging=jar - 在
pom.xml中像引用远程依赖一样写：com.example xxx-sdk 1.0.0
注意：groupId 和 artifactId 不要照抄 jar 文件名，按语义合理命名；版本号建议用数字+点号格式（如 1.2.3），避免含下划线或特殊字符，否则某些插件解析会出错。
如果必须用 systemPath：得手动补进 BOOT-INF/lib
极少数场景（比如 jar 名称冲突、无法改名、又不允许 touch 本地仓库），只能硬上 systemPath，那就得绕过 Spring Boot 默认流程，自己把 jar 塞进最终包里。
核心是改 spring-boot-maven-plugin 配置，用 includes 显式指定要打进 BOOT-INF/lib 的文件：
<plugin><groupid>org.springframework.boot</groupid><artifactid>spring-boot-maven-plugin</artifactid><configuration><includes><include><groupid>com.example</groupid><artifactid>xxx-sdk</artifactid></include></includes></configuration></plugin>
同时仍需保留 system 依赖声明，并确保 groupId/artifactId/version 与 includes 中完全一致。否则插件找不到对应 artifact，静默跳过。
这个方案的问题很实在：CI 环境如果没有提前放好那个 jar，构建直接失败；本地路径写死在 pom 里也会污染协作流程。
替代思路：用 maven-dependency-plugin 解压后编译进项目
当本地 jar 体积小、源码不可得但接口简单，且你愿意承担维护成本时，可以把它“融”进自己的代码里。
- 用
maven-dependency-plugin的unpack目标，把 jar 里的.class或.java（如果有 src.jar）解到src/main/java下 - 删掉原
system依赖，也不用 install，所有类变成自己模块的一部分 - 缺点明显：升级困难、无法享受 Maven 版本管理、可能触发 license 风险
适合临时救急，比如某家银行 SDK 只提供 jar 不开源，又不支持 Maven 中央库，且你只调用其中 2 个类。
真正麻烦的地方不在怎么加，而在于加完之后没人检查它是否真在运行时 classpath 里——建议上线前用 jar -tf target/app.jar | grep xxx 确认 jar 是否出现在 BOOT-INF/lib/ 下，别信 IDE 的绿色对勾。
