当前位置：首页 > 文章列表 > 文章 > java教程 > SpringBoot打Jar方法与插件原理详解

SpringBoot打Jar方法与插件原理详解

2026-03-09 14:33:32 0浏览收藏

本文深入解析了Spring Boot项目打包可执行JAR的核心机制与常见陷阱，重点揭示了为何mvn package后无法生成带BOOT-INF和正确Main-Class的fat jar——根本原因在于spring-boot-maven-plugin未被正确声明或配置，尤其在使用自定义parent时极易遗漏；同时厘清了classifier仅影响文件名而非功能、IDEA Build Artifacts与Maven标准流程的本质差异、以及mainClass显式配置的必要场景与静默失败风险，为开发者提供精准排错路径和可靠构建实践指南。

Spring Boot怎么打包为可执行的jar文件_spring-boot-maven-plugin插件原理解析

为什么 mvn package 后 target 里没生成可执行 jar？

最常见原因是 spring-boot-maven-plugin 没正确声明，或者项目继承了非 Spring Boot 的 parent。如果你用的是 spring-boot-starter-parent，插件默认已配置好 repackage goal；但若用了自定义 parent（比如公司统一父 POM），就必须显式声明插件，否则 mvn package 只打出普通 jar —— 没 BOOT-INF、没 MANIFEST.MF 里的 Main-Class: org.springframework.boot.loader.JarLauncher，自然不能 java -jar 运行。

实操建议：

检查 pom.xml 是否包含 org.springframework.bootspring-boot-maven-plugin
确认是 jar（不是 war 或空）
运行 mvn clean package -X 看日志里有没有 [INFO] Replacing main artifact with repackaged archive —— 没这句就说明 repackage 根本没触发

classifier 和 repackage 配置怎么影响输出文件名？

spring-boot-maven-plugin 的核心动作是 repackage：它把 Maven 默认打包生成的原始 jar（只含 class 和 resources）“重新封装”成带依赖、可执行的 fat jar。而 classifier 是给这个重打包产物加后缀，不影响功能，只改文件名。

比如配置了 exec-dev，最终生成的就是 myapp-1.0.0-exec-dev.jar，而不是默认的 myapp-1.0.0.jar。这在多环境构建时很实用，但要注意：

IDEA 的 Maven 工具窗口里执行 package，不会自动识别 classifier —— 必须命令行加 -Denv=dev 这类参数（如果配置里用了 ${env}）
如果同时存在多个 execution（比如 dev/test/prod），得确保只有一个激活，否则可能生成多个 jar 或覆盖失败
classifier 不影响 java -jar 行为，只要 MANIFEST 正确，名字随便起

IDEA 直接 Build Artifacts 和 mvn package 生成的 jar 有什么区别？

本质区别在于依赖打包策略：mvn package 走的是 Spring Boot 官方流程，产出标准 fat jar（所有依赖进 BOOT-INF/lib/）；而 IDEA 的 Build → Build Artifacts 默认走传统 Java 打包逻辑，即使选了 “with dependencies”，也大概率生成一个普通 jar + 一堆独立 jar 文件散落在同目录 —— 缺少 org.springframework.boot.loader.JarLauncher，java -jar 会报 NoClassDefFoundError 或直接提示 “no main manifest attribute”。

除非你手动在 IDEA 的 Artifact 配置里指定 Main Class 为 org.springframework.boot.loader.JarLauncher，并勾选 “Extract to the target JAR”，否则别信 Build Artifacts 生成的所谓 “可执行 jar”。

本地快速验证？用 mvn spring-boot:run 更靠谱，它不打 jar，但复用相同 classpath 和配置
CI/CD 流水线必须用 mvn clean package，避免环境差异
想看 jar 结构？用 jar -tvf target/myapp.jar | head -20，确认有 BOOT-INF/ 开头的路径

mainClass 配置什么时候必须写？

绝大多数情况不用写 —— 插件会自动从 spring-boot-maven-plugin 的 repackage 阶段扫描项目中唯一的 @SpringBootApplication 类作为启动类，并写入 MANIFEST.MF 的 Start-Class 属性。但以下两种场景必须显式指定：

项目里有多个 @SpringBootApplication 类（比如测试用的嵌入式启动类、集成测试专用入口）
主类不在默认包路径下，或被其他模块引用导致插件扫描错乱（少见，但多模块项目偶发）

配置方式很简单，在插件内加：


  com.example.MyApplication

漏配的后果不是编译失败，而是运行时报 java.lang.IllegalStateException: No SpringApplication classes found 或直接找不到 main 方法 —— 因为 JarLauncher 去找 Start-Class 失败了。

真正容易被忽略的是：这个配置只对 repackage 生效，对 mvn compile 或 mvn test 完全无感；而且一旦写错类名，jar 能生成、也能 java -jar 启动，但会静默加载失败 —— 日志里只有 “Starting Servlet web server” 就卡住，连端口都不监听。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。