企业官网建设流程全解析

1. 项目概述

1.1 为什么你需要学会用IDEA打JAR包

先聊点实在的。我在日常工作中经常被同事问到：“我这个Java项目在IDEA里跑得好好的，怎么发给别人就跑不起来了？”或者是“我明明把项目打成了JAR包，双击却没反应，到底是哪里出了问题？”

这些问题本质上都指向同一个东西：用IDEA把Java项目打包成JAR。不管你是刚学Java的初学者，还是已经写了几年业务代码的开发者，只要你的代码需要脱离开发环境运行，或者说需要交付给部署人员、需要放到服务器上执行，就必须学会这步操作。

先说清楚JAR包是什么。JAR的全称是Java Archive，翻译过来就是Java归档文件。你可以把它理解成一个压缩包，但这个压缩包里装的不是普通文件，而是编译后的.class字节码文件、资源文件、配置文件，还有可选的元数据。Java虚拟机可以直接加载这个包里的类来运行程序。

很多人觉得打包是件很简单的事，点一下Build按钮就完事了。但真正落地的时候，你会遇到各种问题：普通JAR包和可执行JAR包的区别是什么？为什么打出来的包运行时报“找不到主类”？第三方依赖到底有没有被打进去？别人拿到你的JAR包后怎么运行最方便？

这篇文章不绕弯子，直接从IDEA实际操作出发，把普通JAR包和可执行JAR包的完整打包过程、Maven项目的打包方式、常见报错的排查思路全部讲透。适合所有用IDEA开发Java项目的开发者，不管你是学生、刚入职的新人，还是想规范交付流程的老手，这篇文章都能给你一套能直接复用的方案。

1.2 我踩过的那些坑，希望你别再踩

先说一个很典型的场景。去年有个同事从网上找了一个开源项目，用IDEA打开后编译、运行都很正常。结果他想把项目发给另一个同事做接口联调，就随手在IDEA里点了File → Project Structure → Artifacts，把项目打成了一个JAR包。对面同事拿到包后执行java -jar xxx.jar，直接报错：no main manifest attribute, in xxx.jar。

这个报错信息很经典，背后的原因也很有代表性：IDEA默认帮你创建的Artifacts只是一个普通的JAR包，它不会自动帮你指定主类入口，也就是MANIFEST.MF文件里的Main-Class属性是空的。

我当时帮他排查时发现，他在打包时根本没有去Project Structure里配置Main-Class，只是默认生成了一个空的MANIFEST.MF文件。这个问题的本质，就是对IDEA打包机制不熟悉，把“打JAR包”和“打可执行JAR包”混为一谈了。

所以这篇文章我打算从底层逻辑讲起，先把JAR包的内部结构说清楚，再一步步演示操作。这样你遇到问题的时候，至少知道去哪个环节排查，而不至于两眼一抹黑。

2. JAR包的基本结构

2.1 揭开JAR包的神秘面纱

JAR包本质上就是一个ZIP格式的压缩文件，只是扩展名换成了.jar。你用任何解压工具都能打开它。一个典型的JAR包内部结构大致如下：

xxx.jar ├── META-INF/ │ ├── MANIFEST.MF │ └── ... ├── com/ │ └── example/ │ ├── MainClass.class │ └── ... ├── resources/ │ ├── application.yml │ └── ... └── ...

其中最关键的是META-INF/MANIFEST.MF这个文件。它记录了这个JAR包的元信息，包括版本号、创建工具、类路径，以及最重要的Main-Class属性。

举个例子，一个可执行JAR包的MANIFEST.MF文件内容大致是这样的：

Manifest-Version: 1.0 Main-Class: com.example.MainClass

如果你用记事本打开一个打包好的JAR包里的MANIFEST.MF文件，看到的内容基本就是这种格式。Main-Class这一行的值，就是Java虚拟机运行这个JAR包时要加载的入口类。

2.2 普通JAR包与可执行JAR包的区别

很多初学者分不清这两种JAR包，这里我直接用最直白的话解释：

普通JAR包：只是一种分发和归档的格式，它本身没有明确的运行入口。你可以把它当作依赖库引入到其他项目中，也可以把它解压出来查看内容，但你不能直接双击运行它，也不能用java -jar命令启动它。如果你用java -jar去运行一个没有配置Main-Class的JAR包，就会报我们刚才说的那个经典错误。

可执行JAR包：在普通JAR包的基础上，额外在MANIFEST.MF文件里指定了Main-Class，有时还会指定Class-Path来声明运行所需的依赖。只有这种JAR包才能用java -jar命令直接运行。

这两个概念的本质差别，就是MANIFEST.MF文件里有没有Main-Class这一个属性。

在IDEA里打JAR包时，你首先要搞清楚一个问题：你打的这个包是给别人当依赖库用的，还是要能独立运行的程序？两者的操作配置完全不一样。下面我会分场景详细演示。

3. 环境准备与前置条件

3.1 JDK安装与IDEA配置

打JAR包的前提，是你本机已经装好了JDK，并且IDEA能正常编译运行Java项目。

JDK的安装这里不展开讲，但有个核心点必须要提：IDEA使用的JDK版本和项目实际需要的JDK版本必须匹配。如果你项目用的是Java 8的语法特性，但IDEA里配置的是JDK 17，编译时虽然大概率能过，但运行环境如果是Java 8，就会直接报UnsupportedClassVersionError——这个问题我在工作中见得非常多。

检查IDEA里项目JDK配置的方法很简单：

1. 打开IDEA，按快捷键Ctrl+Alt+Shift+S，打开Project Structure窗口。
2. 在左侧选择Project，右侧的Project SDK就能看到当前项目使用的JDK版本。
3. 确认Language Level与SDK版本匹配。

IDEA下载和安装方面，网上资源很多，但我不建议你去搞什么破解版。IDEA社区版完全够用，而且免费，功能上除了部分企业级框架的专门支持外，日常的Java开发、打包、调试都没问题。JetBrains官网直接下载即可。

3.2 确认项目结构是否规范

在打包之前，你需要确认项目的基本目录结构是规范的。一个标准的IDEA Java项目结构通常是这样的：

my-project/ ├── src/ │ └── main/ │ ├── java/ │ │ └── com/ │ │ └── example/ │ │ └── MainClass.java │ └── resources/ │ └── application.properties ├── out/ │ └── production/ │ └── my-project/ ├── .idea/ └── pom.xml (如果是Maven项目)

其中src/main/java目录存放Java源码，src/main/resources目录存放资源文件，out/production目录是IDEA默认的编译输出目录，也就是.class文件生成的地方。

这一步看起来很基础，但很多打包问题其实都出在项目结构不规范上。比如有的人把源码直接放在项目根目录下，而没有放在src目录里，那IDEA在编译时可能根本找不到源码，打出来的JAR包自然是空壳。

4. 在IDEA中打包非Maven项目的JAR包

4.1 场景说明

非Maven项目，也就是我们常说的普通Java项目，没有pom.xml文件，纯粹靠IDEA的编译器来编译和打包。这种项目在初学阶段很常见，也适合用来理解JAR包打包的本质过程。

4.2 步骤一：编译项目，确保代码无报错

在打包之前，务必先编译整个项目，保证没有编译错误。我见过有人连编译都没通过，下面的Build Artifacts按钮都是灰色的，还一直在问为什么点不了。

编译操作的入口有两个：

1. 菜单栏：Build → Rebuild Project。
2. 快捷键：Ctrl+F9。

执行后，观察IDEA底部的Build窗口，确保显示Build completed successfully。此时out/production目录下会生成对应模块的.class文件。

提示：Rebuild Project会强制重新编译所有源码，而不是只编译变更过的文件。在打包之前做一次全量编译是最稳妥的，可以避免因为部分类没有编译而导致JAR包缺失文件。

4.3 步骤二：配置Artifacts

Artifacts是IDEA里用来描述“打包产物如何生成”的配置项。简单理解，你需要告诉IDEA：要把哪些编译好的class文件、哪些资源文件、打包成什么格式、入口类是谁。

操作路径如下：

1. 快捷键Ctrl+Alt+Shift+S，打开Project Structure窗口。
2. 左侧选择Artifacts，点击+号。
3. 选择JAR → From modules with dependencies。

这里有个关键选择页面，需要填几个字段：

• Module：选择你要打包的模块，如果你的项目只有一个模块，直接选默认的即可。
• Main Class：点击右侧的文件夹图标，选择你项目中的入口类，也就是包含main方法的那个类。
• extract to the target JAR：推荐选择此项。它的意思是将依赖库的class文件解压后和项目自身class文件放在一起。如果选择copy to the output directory and link via manifest，则依赖不会被打进JAR包，而是放在外部目录，运行时会因为找不到依赖而报ClassNotFoundException。

我已经在项目里建好了一个示例入口类com.example.MainClass，这里面有一个标准的main方法。接下来直接选择它即可。

4.4 步骤三：打包并验证

配置完成后：

1. 点击OK关闭Project Structure窗口。
2. 发现菜单栏里出现了Build → Build Artifacts选项。
3. 点击后选择Build，或者Rebuild。

打包完成后，IDEA会在项目的out/artifacts目录下生成JAR文件。

此时我们要做两件事：

第一，用压缩工具打开JAR包，确认META-INF/MANIFEST.MF文件里包含Main-Class属性，内容类似这样：

Manifest-Version: 1.0 Main-Class: com.example.MainClass

第二，打开命令行终端，进入JAR包所在目录，执行：

java -jar my-project.jar

能正常输出程序的运行结果，说明这个包是可用的。

4.5 普通JAR包（无主类）怎么打

如果你只需要把项目打成一个供其他人引入的依赖库，不需要直接运行，那就不需要指定Main-Class。

操作上仍然是在Project Structure → Artifacts里新建一个JAR包，但类型选择Empty。然后把你想要打包的编译输出目录添加进去即可。

这种方式打出来的JAR包没有主类入口，别人引用它的时候是通过import语法来使用里面的类，而不是通过java -jar来运行。

5. 在IDEA中打包Maven项目的JAR包

5.1 Maven项目的特殊之处

如果你是用Maven管理的项目，项目根目录下会有pom.xml文件。相比普通Java项目，Maven项目的打包方式更规范，也更方便管理依赖。

Maven项目打JAR包的方式有几种，我强烈推荐用Maven生命周期命令，而不是用IDEA的Artifacts功能。因为Maven项目用Artifacts打包时，经常会遇到依赖缺失、构建环境不一致的问题，而Maven自己打出来的包，结构更标准，也更容易排查问题。

还有一个业界普遍使用的技巧：用Spring Boot的Maven插件打可执行JAR包。Spring Boot的JAR包和普通JAR包有点不一样，它会生成一个特殊的fat JAR，把项目所有依赖全部塞进去，同时使用自定义的类加载器来加载这些第三方类。这个后面再细说。

5.2 用Maven生命周期打包

如果在IDEA右侧的Maven面板看不到，你可以通过View → Tool Windows → Maven打开。

在Maven面板里，展开项目模块的Lifecycle，双击package命令，Maven就会自动执行编译、测试、打包全流程。这个过程中，Maven会：

1. 执行clean清理旧的编译产物。
2. 执行compile编译源码。
3. 执行test运行单元测试。
4. 执行package将项目打包成JAR包。

这个过程中最容易出现的问题就是测试不通过导致打包失败。如果只是临时打包不想执行测试，可以在Lifecycle面板上方的执行命令处，输入：

mvn package -DskipTests

我个人的习惯是：本机能正常跑测试的情况下，先不要跳过测试。因为你不知道这次改动会不会引入回归问题，跳过测试把包打出来，到了测试环境再报错，反而更浪费时间。但如果只是为了快速交付一个临时包，跳过测试也无可厚非。

打包完成后，JAR包会生成在项目的target目录下，文件名为项目名-版本号.jar。

5.3 Maven打出的JAR包不可运行怎么处理

这里有必要单独讲一下，普通Maven项目用mvn package打出来的JAR包，默认只是一个普通JAR包，它不会把依赖打进包里，也不会自动配置Main-Class属性。所以很多人在这一步会遇到：明明打包成功了，但执行java -jar却报错“找不到主清单属性”或“找不到类”。

解决办法有两种：

方法一：配置maven-assembly-plugin

在pom.xml里加入以下插件配置：

<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>3.6.0</version> <configuration> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> <archive> <manifest> <mainClass>com.example.MainClass</mainClass> </manifest> </archive> </configuration> <executions> <execution> <id>make-assembly</id> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> </plugin> </plugins> </build>

配置完成后执行mvn clean package，在target目录下会生成xxx-jar-with-dependencies.jar，这个就是包含所有依赖的可执行JAR包。

方法二：使用Spring Boot Maven插件

如果你的项目是基于Spring Boot的，可以直接在pom.xml里配置spring-boot-maven-plugin：

<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build>

之后执行mvn clean package，生成的JAR包就是可执行的fat JAR，直接java -jar即可运行。

6. 操作实战与核心环节实现

6.1 非Maven项目完整打包演示

为了让大家看得更明白，我用一个最简单的Java项目来做完整演示。

项目结构如下：

demo-pack/ ├── src/ │ └── com/ │ └── example/ │ ├── MainClass.java │ └── GreetingService.java

MainClass.java内容：

package com.example; public class MainClass { public static void main(String[] args) { GreetingService service = new GreetingService(); String message = service.buildGreeting("打包测试"); System.out.println(message); } }

GreetingService.java内容：

package com.example; public class GreetingService { public String buildGreeting(String name) { return "Hello, " + name + "!"; } }

我们按照前面的步骤操作：

第一步，Ctrl+F9编译项目，确认Build completed successfully。

第二步，Ctrl+Alt+Shift+S打开Project Structure → Artifacts，新建JAR包。

第三步，选择From modules with dependencies，在Main Class位置选择com.example.MainClass。

第四步，点击OK关闭窗口，然后Build → Build Artifacts → Build。

此时在out/artifacts/demo_pack_jar目录下会生成demo-pack.jar。

打开命令行执行：

java -jar demo-pack.jar

输出结果：

Hello, 打包测试!

这就是一个完整的打包流程，是不是很简单？

6.2 带第三方依赖的项目打包实战

上面的示例项目没有依赖任何第三方库，打出来的包自然比较干净。但实际开发中，项目几乎都会依赖第三方JAR包，比如MySQL驱动、HttpClient、fastjson等。

我先建一个需要依赖第三方库的演示项目，用它来展示带依赖项目的打包全过程。

测试代码里要使用fastjson来构造JSON字符串：

package com.example; import com.alibaba.fastjson.JSONObject; public class MainClass { public static void main(String[] args) { JSONObject obj = new JSONObject(); obj.put("name", "打包测试"); obj.put("type", "带依赖演示"); System.out.println(obj.toJSONString()); } }

在这个项目中，fastjson是一个独立的外部依赖库，我通过手动添加的方式引入到项目中。如果你用的是Maven项目，不需要手动下载JAR包，直接在pom.xml里声明依赖坐标即可。

配置Artifacts的过程和之前一样，在Project Structure → Artifacts → JAR → From modules with dependencies里设置Main Class。

这里有一个非常关键的选项，页面底部会有两个单选：

• extract to the target JAR
• copy to the output directory and link via manifest

我强烈推荐选择extract to the target JAR，因为这样打出来的包是一个完整的fat JAR，所有依赖都在里面，发给任何人、放到任何机器上都能直接运行。第二种方式生成的JAR包体积很小，但依赖在外部目录，运行时需要额外设置Class-Path，传播和使用都很麻烦。

打包完成后，你可以用解压工具打开JAR包，在com/alibaba/目录下能看到fastjson的class文件，说明依赖已经被正确打进包里了。

然后执行java -jar demo-with-deps.jar，看到输出结果：

{"name":"打包测试","type":"带依赖演示"}

6.3 指定JAR包入口函数的特殊需求

有时候依赖方会明确要求你提供一个JAR包，而且程序入口不是标准的main方法签名，或者一个JAR包里包含多个入口类，需要用户自己指定执行哪个类。

这种情况在IDEA里有几种处理方式：

方式一：通过MANIFEST.MF指定主类

如果你是用Artifacts打包，重新进入Project Structure → Artifacts，选择当前已有的Artifacts，在Output Layout里右键点击META-INF目录，选择Create Manifest。

然后手动编辑MANIFEST.MF：

Manifest-Version: 1.0 Main-Class: com.example.CustomEntry

如果你用的不是IDEA的Artifacts，而是命令行工具，也可以用类似方式指定：

jar cfe my-app.jar com.example.CustomEntry -C out/production/classes .

这里的e选项就是指定入口类。

方式二：用javap工具定位类

如果你的程序入口不在平时熟悉的类里，你想确认这个JAR包里到底哪个类有main方法，可以在命令行里用jar tf查看JAR包内容，然后再用javap工具反编译查看类的签名：

jar tf my-app.jar javap -classpath my-app.jar com.example.HiddenEntry

这样可以确认某个类是否包含可运行的main方法。关于反编译JAR包的问题，如果你需要查看某个类在JAR包里的实现逻辑，可以使用IDEA自带的反编译功能。具体操作是：把JAR包添加到项目的Libraries中，然后在IDEA的Project窗口里双击打开这个类，IDEA会自动反编译并展示源码。也可以使用开源的CFR、Procyon等工具。但需要注意，反编译只能作为参考，不是所有字节码都能完美还原成可读性高的源码。

6.4 加快JAR包打包速度的小技巧

最新的网络热搜词里有人专门问“如何优化加速JAR打包速度”，说明这个问题确实困扰了不少人。

如果你用的是Maven项目，且项目比较大，打包慢通常有以下几个原因：

• 依赖下载慢：首次打包时要下载大量依赖，这是最耗时的环节。解决方案是使用国内镜像源，比如阿里云仓库镜像。在settings.xml里配置镜像源，下载速度能有质的提升。
• 重复执行测试：mvn package默认会执行测试，如果测试用例很多，耗时很长。临时打包时可以加-DskipTests跳过测试阶段。
• 没有使用增量编译：IDEA默认会做增量编译，但如果你频繁执行mvn clean，每次都会全量重新编译。建议在代码变更不大、且是临时打包时，不要执行clean命令，直接mvn package。

还有一个小技巧：在IDEA的Maven面板中，把打包命令Tail Log里看到的核心日志对应的问题先解决掉，这样可以避免反复打包失败浪费的时间。

我个人实测，配置了国内镜像源后，一个依赖量较大的Spring Boot项目，首次打包时间能从5分钟以上降到1分多钟，体验提升非常明显。

7. 常见错误与排查处理

7.1 “no main manifest attribute”的根源

这个报错是打包场景里最常见的。我已经在前文提过一次，这里再详细展开一下。

no main manifest attribute, in xxx.jar这个错误，翻译过来就是：在xxx.jar这个文件里，找不到主清单属性。主清单属性指的就是MANIFEST.MF文件里的Main-Class。

产生这个报错无非以下几种原因：

1. 打包时没有配置Main-Class属性。
2. 配置了Main-Class，但类名包含模块名前缀，格式不正确。
3. JAR包被某些工具重新打包过，MANIFEST.MF文件被覆盖了。

排查方法很简单：用压缩工具打开JAR包，找到META-INF/MANIFEST.MF，看看内容里有没有Main-Class这一行。如果没有，说明打包配置没生效。

解决方式也简单：

• 如果是IDEA Artifacts打包：重新打开Project Structure → Artifacts，确认Main Class配置无误后重新Build。
• 如果是Maven项目：按前面讲的配置maven-assembly-plugin，或者检查pom.xml里是否已配置了spring-boot-maven-plugin。

7.2 “ClassNotFoundException”与“NoClassDefFoundError”

这两个报错本质上都是运行时找不到某个类，区别在于：

• ClassNotFoundException：运行到某一行时才去加载类，结果类不在classpath里。
• NoClassDefFoundError：编译时类存在，但运行时无法加载。

如果执行java -jar时出现这类报错，第一反应应该是：依赖没有被打进JAR包里。

如果你在IDEA里用的是Artifacts打包，检查一下Artifacts配置页面里的Output Layout区域，看依赖库是否被包含进去了。正常情况应该能看到Available Elements列表和Output Layout区域的对应关系，你要把<project> compile output和所有library都拖进左边的输出区域。

如果你是Maven项目，检查pom.xml中是否有<scope>provided</scope>或<scope>system</scope>的依赖。这类依赖在打包时默认不会打进去。比如Servlet API就是典型的provided依赖，它在Tomcat运行环境中有，但如果你在本地打JAR包想独立运行，就需要手动排除或调整scope。

7.3 端口被占用导致的运行失败

还有一种情况和打包本身无关，但和运行JAR包强相关：项目本身能跑，但执行java -jar后报端口被占用。

这个问题的种类很多，比如用Spring Boot开发时，默认端口8080可能被其他进程占用了。排查方式：

Windows下：

netstat -ano | findstr 8080

Linux/Mac下：

lsof -i:8080

找到占用进程后，杀掉或者换端口即可。

7.4 中文乱码问题

如果你的程序里包含中文输出，但执行JAR包时出现乱码，很可能是控制台的编码格式不是UTF-8。

IDEA里你看到的是正常中文，是因为IDEA自己设置了UTF-8编码，但命令行终端的默认编码可能是GBK或者别的什么。

解决方法是在运行命令时明确指定编码：

java -Dfile.encoding=UTF-8 -jar my-app.jar

如果是Windows的cmd，还可以先执行chcp 65001切换到UTF-8再运行。

7.5 常见错误速查表

8. 进阶：反编译JAR包与源码混淆

8.1 别人给你JAR包，怎么看它内部结构

实际工作中，你要么是自己打JAR包发给别人，要么是接手别人打好的JAR包去维护。后者这种场景里，反编译是一个很有用的技能。

热词里有个词叫“反编译jar”，我简单讲下常用的工具。

IDEA自带反编译：直接把JAR包拖进IDEA里，或者通过Project Structure → Libraries → + → Java添加JAR包后，在Project窗口里找到对应的类，双击即可看到反编译后的源码。IDEA集成的是FernFlower反编译器，还原度相当高。

命令行工具：如果你不想开IDEA，用CFR也很方便。下载CFR的JAR包后，命令行执行：

java -jar cfr.jar xxx.jar --outputdir ./output

就会在output目录下生成反编译后的.java文件。

8.2 防止反编译？说说源码混淆

与反编译对应的另一个热词是“源码混淆”。

如果你要让JAR包交付给客户，又不想让别人轻易看懂核心逻辑，可以考虑做代码混淆。常见的Java混淆工具包括：

• ProGuard：老牌工，可以把类名、方法名、字段名改成无意义字符，删除未使用的代码，甚至做代码优化。
• Allatori：商业级的混淆工具，混淆强度很高。
• yGuard：开源但活跃度一般。

需要说明的是，混淆只能提高逆向的门槛，不能完全防止反编译。因为JVM要能加载类，字节码里必然保留了可执行的信息，唯一能做的是让这些信息变得难以理解。

如果你的项目对安全性要求很高，我建议在架构层面做防护，比如把核心算法放到服务端，客户端只保留调用逻辑，而不是指望混淆工具能一劳永逸。

9. 不同场景下的打包方案选择

9.1 依赖方的通用JAR包与可执行JAR包

之前的标题和热词里涉及到“jar包指定函数入口”以及“jar包反编译”这样的需求，说明很多人已经在处理别人交付的JAR包，而不只是自己闷头写代码了。

我先梳理一下什么场景下应该打什么类型的包：

9.2 每隔一段时间就要手动打包？考虑用脚本

如果你隔三差五就要打一次JAR包，那手动点IDEA确实效率太低了。我建议你写一个简单的脚本，一键完成编译、打包、拷贝到指定目录的操作。

Windows下的bat脚本示例：

@echo off echo ====== 开始打包 ====== call mvn clean package -DskipTests copy target\my-app-1.0.0.jar D:\deploy\ echo ====== 打包完成 ====== pause

Linux/Mac下的shell脚本示例：

#!/bin/bash echo "开始打包" mvn clean package -DskipTests cp target/my-app-1.0.0.jar /opt/deploy/ echo "打包完成"

这样每次构建只需执行一个脚本，不用再打开IDEA的Maven面板等待构建结束。

9.3 一个特殊场景：本地打好的包，别人机器上运行报版本错误

有一种问题经常在前后端联调时出现：你在IDEA里用JDK 17编译打包，对方机器上装的是JDK 8，结果运行时报UnsupportedClassVersionError。这个错误的含义是：class文件编译所用的Java版本，高于当前JVM支持的版本。

排查方式：

先确认对方机器的Java版本：

java -version

再看自己打包时用的JDK版本。如果编译版本高于运行版本，要么让对方升级JDK，要么你在Maven中指定编译版本为较低版本，比如：

<properties> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> </properties>

这种方式在混合环境部署时特别实用。

10. 常见问题排查实录

10.1 双击JAR包无法启动

很多初学者辛辛苦苦把JAR包打出来，然后双击，发现窗口一闪而过，或者直接没反应。

首先要明确：JAR包并不是双击就能运行的程序。只有在系统里正确安装了Java运行时，并且将.jar文件关联到了javaw.exe，双击才可能有效。而且即使双击有效，控制台的输出也看不到，程序出错的话你完全不知道发生了什么。

所以我强烈建议：不要用双击方式运行JAR包，一律用命令行启动。

java -jar your-app.jar

这样日志能直接打印在终端里，出错了也能看到栈信息，排查起来很容易。

10.2 打包后文件缺失，比如配置文件、图片、XML等

打包后发现资源文件没进JAR包？这也非常常见。

在IDEA的Artifacts配置页面里，左侧Available Elements区域会把项目的所有元素列出来，包括编译输出、资源目录、依赖库等。你需要把src/main/resources或对应模块的资源目录也拖到右侧的Output Layout里。

如果是Maven项目，默认情况下会打包resources目录下的所有文件，但如果某些文件被过滤规则排除了，也会导致资源缺失。排查方法就是打开最终JAR包，看resources或相对路径下是否有对应的文件。

如果使用maven-assembly-plugin，可以加一个显式的资源声明：

<resources> <resource> <directory>src/main/resources</directory> </resource> </resources>

10.3 用Spring Boot打的JAR包解压后结构很奇怪

如果你用spring-boot-maven-plugin打包，解压后会发现里面有一个BOOT-INF目录，项目的class文件在BOOT-INF/classes下，依赖在BOOT-INF/lib下，而且传统的META-INF/MANIFEST.MF里的Main-Class指向的是org.springframework.boot.loader.JarLauncher，而不是你自己的业务类。

这不是出错，而是Spring Boot自定义的加载方式。Spring Boot的启动器会通过自定义的类加载器去加载BOOT-INF/classes和BOOT-INF/lib下的类，所以即便你的业务类不直接出现在Main-Class里，也能被正确加载。

如果你需要把这个Spring Boot JAR包当作普通依赖引入其他项目，是不行的。需要额外生成一个只包含自己类的普通JAR包，或者用mvn package时配合classifier配置来区分。Spring Boot的JAR包本身就是为独立运行设计的，别拿它当普通依赖用。

11. 写在最后的几点心得

如果你是从头读到这里的，可以感受到，用IDEA打JAR包这件事本身并不复杂，真正的难点在于搞清楚背后的运行机制。我前面讲了这么多，总结起来其实就三句话：

第一，搞清楚JAR包的类型。普通JAR包和可执行JAR包是两个不同的东西，你要在动手之前想清楚打哪种。给依赖方用，打普通JAR包；要独立运行，打可执行JAR包。

第二，学会阅读报错信息。no main manifest attribute告诉你是入口没配好，ClassNotFoundException告诉你是依赖没打进去或classpath不对，UnsupportedClassVersionError告诉你是JDK版本不一致。报错信息是排查问题的第一线索，别一上来就怀疑工具。

第三，把重复的操作自动化。如果打包是你日常频繁要做的事，用Maven的mvn package加上脚本，远比每次打开IDEA手动点菜单高效得多。

我个人在实际操作中还有一个习惯：每次打包完成后，我都习惯用解压工具打开JAR包快速检查一遍，确认MANIFEST.MF配置正确、关键类在里面、依赖没有缺失。这个习惯帮我规避了很多低级问题，每次都是花半分钟的时间，省掉后续的沟通和返工成本。

最后分享一个小技巧：如果你是做Java服务端开发的，建议养成每次构建都带上版本号的习惯，比如my-app-20250112.jar，或者用Maven的版本号自动加上日期后缀。这样部署到服务器上后，你一眼就能知道跑的是哪个时间点构建的包，排查线上问题时能节省大量时间。

好，这篇关于IDEA打包JAR的文章就到这里。如果你在实际操作中遇到了其他问题，建议先用压缩工具把JAR包打开看看，对照这篇内容逐一排查，大概率能找到原因。