先说个挺有意思的现象很多人辛辛苦苦把 Java 项目写好、测试完交付给不懂技术的人使用时就卡住了。你跟对方说双击运行 start.bat他问你什么叫 bat你说先装个 JDK 配置一下 JAVA_HOME他直接把这个工具丢回来说你不是说写好了吗怎么还要装环境。所以把 Java 项目做成 exe 文件是很多 Java 开发者迟早要面对的一件事。网上关于 exe4j 的教程不少但大多只讲了最顺的那条路真正动手时遇到的各种提示、控制台窗口怎么处理、IDEA 里怎么把依赖一起打进去反而没人细讲。这篇文章我就把用 exe4j 把 Java 项目从 IDEA 打包成 jar、再从 jar 转成 exe 的完整过程拆开揉碎讲一遍包括运行 exe 时弹 exe4j 提示的成因和处理方法、控制台窗口的显示规则把这些只会在实战中碰到的细节都交代清楚。1. 动手之前exe4j 在打包方案里的定位与适用场景先说结论exe4j 不是编译器也不是运行时它就是一个包装器wrapper。它做的事情是把你的 jar 文件、依赖库、图标、启动参数等打包成一个 exe 外壳这个 exe 在运行时自己去找 JRE然后用 Java 命令启动你的 jar 里的主类。1.1 为什么选择 exe4j 而不是其他方案Java 项目转 exe 的方案其实不少我在不同项目里都试过简单做个对比方案原理优点缺点适用场景exe4j生成一个启动器 exe运行时调用 JRE配置直观官方提供 GUI 向导生成出来的 exe 只是个壳目标机器必须有 JRE可一起分发中小型工具、给客户交付、内部系统启动器jpackageJDK 自带的打包工具JDK 14不需要额外安装软件可生成安装包和运行时镜像配置相对繁琐对复杂依赖的定制能力一般官方推荐的标准方案GraalVM Native ImageAOT 编译成原生可执行文件启动快、无 JRE 依赖、内存占用低构建时间长对反射、动态代理支持差很多框架配置起来会崩溃追求极致的启动速度、交付单文件的场景launch4j与 exe4j 类似的开源方案免费、开源、支持命令行构建界面不如 exe4j 直观个别 JVM 参数处理不同想免费闭着眼用打包成 exe 依赖 的裸启动器就是 cmd / bat 配合 sfx 自解压极轻量本质上是压缩包自解压容易被当成病毒误报临时方案别用我对 exe4j 的评价是它是一个非常务实的中小项目交付工具。如果你做的项目不是特别庞大依赖没有几十上百个 jar用 exe4j 可以少走很多弯路。GraalVM 虽然听起来高级但遇到 Spring Boot 项目或者用到动态代理很容易让你怀疑人生。jpackage 是趋势不过初次接触时学习成本比 exe4j 略高。1.2 exe4j 的版本选择和运行环境用 exe4j 之前先搞清楚两个重要概念exe4j 本身是 32 位还是 64 位决定了它能搜索到哪种 JRE它支持的 Java 版本也有限制。去 exe4j 官网下载时会看到两个版本32 位版本和 64 位版本。这里有一个常见的坑如果你下载的是 32 位的 exe4j那么最终生成的 exe 在运行时只能找到 32 位的 JRE。万一目标机器上只装了 64 位的 JDK你的 exe 就会弹提示说找不到 Java Runtime Environment。所以我个人建议直接下载 64 位版本当前主流机器和 JDK 都已经是 64 位了没必要给自己找麻烦。另外注意 exe4j 的授权机制。没有注册码的时候它会以Evaluation模式运行生成的 exe 每次启动都会弹一个 exe4j 的试用提示窗口这个细节很多人会掉坑里。下面第 4 章我会详细讲怎么识别和处理。2. IntelliJ IDEA 打包 jar 的两条路线想把项目转成 exe第一步永远是先把 Java 项目打包成可运行的 jar。这里我按照项目类型拆成两条路普通 Maven/Gradle 项目怎么打、Spring Boot 项目怎么打因为很多人在这一步就卡住了——打出来的 jar 双击没反应或者运行时报no main manifest attribute。2.1 普通项目在 IDEA 中打包可执行 jar如果项目不是用 Spring Boot 这种自带插件的方式管理那打包路径是File-Project Structure...也可以按CtrlAltShiftS然后点击左侧的Artifacts。在 Artifacts 面板里点击号依次选择JAR-From modules with dependencies...。此时 IDEA 会弹出一个对话框让你选择 Main Class主类。选定之后下方有一个Directory for META-INF/MANIFEST.MF这里我强烈建议你点右侧的文件夹图标把输出路径指定到你项目的src/main/resources目录下并且不要让它默认生成到META-INF文件夹根部。这一步很多人忽略了。如果 MANIFEST.MF 生成的位置不对后续每次重新编译、清理项目时它可能会丢失或覆盖错乱导致 jar 包找不到主类。保存后在 IDEA 顶部菜单栏选择Build-Build Artifacts...再点击BuildIDEA 就会开始打包。默认输出位置在项目根目录的out/artifacts/下。打开生成的 jar 包如果里面有META-INF/MANIFEST.MF且文件中包含这样一行Main-Class: com.example.MainClass那就说明这个 jar 已经是可执行 jar 了可以用java -jar xxx.jar跑通。2.2 Maven 项目的外部依赖处理策略Maven 项目的 jar 包和普通 IDEA Artifacts 的打包逻辑不太一样。如果你直接运行mvn package生成的 jar 一般只包含你自己写的 class 文件第三方依赖不会打进去这个 jar 单独用java -jar跑会报ClassNotFoundException。解决办法有三种第一种用maven-assembly-plugin插件生成 fat jar也叫 uber-jar把依赖全部解压后合并到一个 jar 里。第二种用maven-shade-plugin这个插件更常用它不仅能打 fat jar还能处理依赖冲突和META-INF下的同名文件合并。在 pom.xml 里配置一下然后执行mvn clean package生成的 jar 就带上了所有依赖。第三种依赖不打进 jar而是放到 jar 旁边的 lib 目录里。这种方式配合 exe4j 很灵活因为 exe4j 可以让你自由配置 classpath不必非要用 fat jar。我实际项目里一般倾向第三种配合 exe4j 使用。原因很简单fat jar 对 exe4j 没坏处但如果依赖里有本地 jar比如公司内部的 SDK这些 jar 没有发布到 Maven 仓库时shade 插件在解析依赖时也够烦的。把依赖放在外部目录反而更直观。2.3 Spring Boot 项目的特殊打包方式Spring Boot 项目的 jar 包打法和普通项目完全不同。如果你用mvn package直接打默认生成的 jar 是可执行 jar但它的主类不是你的SpringBootApplication类而是org.springframework.boot.loader.JarLauncher内部的 class 文件都放在BOOT-INF/classes里。这个 jar 单独跑没问题但如果你直接把它拖进 exe4j 里指定 Main-Class 写你自己的启动类运行时会各种ClassNotFoundException或者找不到配置。正确做法是使用spring-boot-maven-plugin的repackage目标它会生成一个可执行 jar同时还会生成一个.jar.original备份。这个可执行 jar 配合 exe4j 时Main-Class 不写你自己的类而是写org.springframework.boot.loader.JarLauncher。从实践来看Spring Boot 项目转 exe 用 exe4j 反而有点笨重因为它本身会一次性加载所有依赖启动速度已经有点慢了。如果启动时间让你很难受我建议直接考虑 jpackage 或者 GraalVM。但如果你就是要一个简单的 exe 给客户双击exe4j 依然是最快出效果的一条路。3. 用 exe4j 把 jar 变成 exe完整配置流程环境确认无误、jar 包也打好了接下来就进入核心环节exe4j 的具体操作。启动 exe4j 后点击界面左侧的Project type这一步选择JAR in EXEmode。这个模式的作用就是把 jar 包通过 exe 这个壳启动exe4j 会在运行时为你拼出完整的启动命令。另一项Regularmode 是直接启动一个 class 文件适合非常简单的场景我们一般不用。3.1 应用信息与可执行文件命名的几个细节点击Next进入应用信息配置页面这里有几个输入框值得注意Short name生成后 exe 的显示名称建议用简短的英文避免中文可能引发的编码问题。Executable name实际生成的 exe 文件名例如MyTool.exe。Icon File可选的图标文件支持.ico格式。如果没有现成的 .ico 文件可以先不设置等全部流程跑通后再回头加图标。这些配置都可以保存成.exe4j项目配置文件后续想修改时直接双击配置文件再打开不用重新走一遍向导。3.2 Java invocation 配置Main Class 与 Classpath 的正确姿势到Java invocation这一步是整个 exe4j 最核心的配置点。你需要点击绿色号手动添加一个 Java 调用。Main class填写你 jar 包的入口类必须是全限定类名比如com.example.MainApp不带.class后缀。如果 jar 是用 Spring Boot 打的这里要填org.springframework.boot.loader.JarLauncher。Classpath需要把你打包好的 jar 文件加进去。注意这里是 exe4j 最容易出错的点之一——它有Archive和Directory两种模式。如果你的 jar 是 fat jar选择Archive模式把 jar 添加进去即可如果你的依赖在外部 lib 目录点击目录旁边的号添加Directory然后选中 lib 文件夹。Initial memory和Maximum memoryJVM 的-Xms和-Xmx参数按需设置。比如打包一个桌面小工具让用户跑起来后内存别太紧张可以填64和1024。Additional Java parameters这里是填额外 JVM 参数的地方。要注意字符串里如果有空格或特殊字符建议用引号包起来。完成这一步后点击 Next 到 JRE 搜索配置。3.3 JRE 搜索顺序与预定义目录exe4j 运行的机制本身不包含 Java 代码的执行环境它只是找到 JRE 再去启动你的 jar。所以它必须知道去哪里找 JRE。在JRE search这一页你可以通过上下箭头调整 JRE 的搜索顺序。第一次使用可以直接点击Advanced勾选Use a custom directory然后填入目标机器上的 JRE 安装路径比如C:\Program Files\Java\jre8。这是本地测试最快的方法。不过真实交付场景中更稳妥的做法是把 JRE 目录跟随 exe 一起发布比如在 exe 同目录下放一个名为jre的文件夹然后在配置里添加一个注册项jre路径留空。exe4j 在 exe 启动时会自动先找同目录下的jre文件夹。这一点非常关键因为客户电脑上可能根本没有 Java 环境。打包 JRE 的方式我放到第 6 章细讲。3.4 生成 exe 并验证最基本的启动所有配置完成后点击 Next 直到Finishexe4j 会在你指定的输出路径生成一个 exe 文件。先不要急着分发直接在本地双击运行一下。如果你的开发环境已经配好了 JDK且 exe4j 配置的 JRE 路径准确那么这个 exe 应该能正常启动你的程序看到控制台窗口或 GUI 窗口。如果此时看到异常提示不要慌常见问题我在下面两章专门展开。4. 运行 exe 时弹出 exe4j 提示具体成因与排查链路很多人第一次运行生成后的 exe会弹出一个跳转页面或者提示窗口依稀能看到 exe4j 字样。这个现象单看标题有点吓人其实拆开来说不外乎那几类情况我按出现频率从高到低给你排一遍。4.1 未注册版本的 Evaluation 弹窗第一种弹窗是最常见的exe 能正常运行但在程序启动前会先弹出一个小的 exe4j 引导窗口上面写着 This executable was created with an evaluation version of exe4j然后让你点击OK继续或者显示一个网页链接。这说明你使用的是 exe4j 的试用版。它并不是出错了只是每次启动都要走一遍这个确认。解决方式也很简单——购买授权并注册。在 exe4j 的主界面点击Enter License输入注册码然后再重新生成一次 exe弹窗就会消失。这里有一个我踩过的坑直接修改 exe4j 的配置文件或者把许可证文件拷过来并不能清除掉已经生成的 exe 里的弹窗逻辑。你必须重新用已注册的 exe4j 打开项目、再点一次 Save Generate重新生成 exe 文件。4.2 找不到 JRE 的提示与处理顺序第二种弹窗长这样一个纯文本窗口提示 No JVM could be found on your system或者 Failed to find JRE path。出现这个提示非常值得你留意因为这说明你的 exe 在目标机器上没有找到可用的 JRE。排查顺序建议这样来在 exe 同目录下打开一个 CMD执行java -version确认当前机器是否真的装了 Java。如果没有输出说明机器上就没有 JRE需要给这台机器安装 JRE或者采用第 6 章的携带 JRE 目录方案。如果机器上有 Java检查你装的是 32 位还是 64 位。我之前遇到过一台电脑同时装了 JDK 8 和 JDK 17但环境变量 PATH 只指向了 JDK 17而 exe4j 项目里配置的搜索顺序只认 JDK 8 的目录导致找不到。exe4j 搜索 JRE 的优先级从高到低一般是exe 同目录下的 jre 文件夹遮罩配置、注册表中记录的 JRE、JAVA_HOME 环境变量、PATH 里的 java。明白了这个顺序你就知道该怎么调了。4.3 JVM 位数不匹配导致的高频问题第三种弹窗比较隐蔽它可能不是一个明确的找不到 JRE而是程序启动到一半就崩溃或者提示UnsupportedClassVersionError。这个现象在 exe4j 里通常由两个原因造成。一个原因是 jar 编译时的 Java 版本高于 JRE 运行版本。比如你用 JDK 17 编译的项目但 exe4j 找到了 JRE 8 来启动必然报UnsupportedClassVersionError。解决办法就是在 exe4j 的执行配置中把 JRE 搜索顺序调到正确的 JDK 17 目录或者干脆Additional Java parameters中不设置任何内容只调整搜索路径。另一个原因是 32 位 exe4j 和 64 位 JRE 的错位。前面说过如果你误装了 32 位 exe4j它会拒不认识 64 位 JRE。这个错误在提示信息里常常是This executable expects the 32 bit version of JVM虽然翻译得有点绕但看到这句第一反应就应该是exe4j 本身是 32 位程序。处理方式也比较简单下载 64 位的 exe4j打开原来的.exe4j配置文件重新生成 exe。或者给目标机器补装 32 位 JRE但都 2025 年了我强烈不推荐再为这事情折腾 32 位 JRE。4.4 品一品DLL not found的报错还有一种举报窗口信息是The dynamic link library msvcr100.dll could not be found或类似。这类报错看起来像是 Java 的问题但实际是 exe4j 生成的 exe 依赖了 VC 运行库。exe4j 默认生成的 exe 会有一些 Microsoft Visual C 运行时的依赖。在 Windows 10 以上系统一般是内置的但在精简版系统或 Server Core 上偶尔会有问题。遇到这种可以考虑在配置页面把兼容性选项调整一下或者检查一下系统运行库是不是被精简过。如果上面几类弹窗你都排查完了还是有问题我建议你暂时不要双击 exe而是在命令行里手动执行 jar确认程序本体没问题再回头检查 exe4j 的配置。这样能把程序问题和打包问题分开定位是效率最高的排查方式。5. 控制台窗口显示Console 与 GUI 两种模式的取舍很多人用 exe4j 打包完双击运行时会弹出一个黑乎乎的 cmd 控制台窗口程序跑起来之后还关不掉非常影响体验。也有些人反过来自己的程序明明需要看控制台输出打包之后却发现什么都没有。这两种情况都和 exe4j 的应用类型设置有关。5.1 exe4j 的 Application Type 和它的实际影响在向导的第一页Project type之后有GUI application和Console application两种选择。这个设置不是表面上的要不要黑框它的真实含义是GUI applicationexe4j 启动 JVM 时不会分配控制台窗口适合带有 Swing/JavaFX 界面的程序。如果程序在启动时往System.out打印了信息这些输出是看不到的。Console applicationexe4j 会给 JVM 关联一个控制台窗口程序里所有的System.out和System.err输出都会实时显示在这个窗口里。所以你的选择应该取决于程序的实际形态而不是哪个好看。如果我做的是一个无界面的后台任务工具比如文件批量处理、数据库迁移脚本我会选Console application因为用户需要看到进度和错误信息。如果我做的是一个图形界面的小工具那就选GUI application就不需要那个黑色窗口了。5.2 想隐藏控制台但又要保留日志输出的处理方式有时候你的程序是 GUI 应用但某段逻辑里用到了System.out.println去调试又不想让用户看到一个碍眼的黑框。此时我的建议是用GUI application类型然后把日志输出改为写入文件。可以通过Additional Java parameters加上这样的 JVM 参数-Dlog4j.configurationFilelog4j2.xml或者如果你的程序里没有引入日志框架想让系统输出重定向到文件也可以在这一步加上console.log 21不过这个写法对 exe4j 不太友好exe4j 不会解析这种 shell 重定向符。更干净的办法是你在代码里自己判断使用日志框架把输出写到文件而不是依赖控制台重定向。5.3 高级选项里让 Console 按需显示exe4j 在Advanced options里有一个Allow console window选项勾选它之后生成的 exe 会兼容两种形态默认不显示控制台但如果用户从命令行启动并传入了特定参数就可以让控制台显示出来。这个功能适合命令行工具公司内部使用比如需要调试时就让人在 cmd 里跑一下 exe看到报错。使用方式简单说下程序里读取启动参数如果含--console则调用AttachConsole相关处理。exe4j 对此有对应的 Java 侧 API 支持不过一般小项目用不到这个深度知道这个选项存在、别在导出时误勾选了就行。5.4 一个真实项目里的选择案例我去年给一个数据清洗工具做过打包。工具本身是 Swing 界面但如果从菜单里触发批量处理操作员希望能看到处理到第几条了否则会以为程序卡死。当时我先用了GUI application结果处理进度看不到改成Console application后GUI 界面在弹出时反而显得突兀每次启动都会闪一个黑框。最终的处理是选GUI application然后在代码里用 Swing 的进度条展示处理状态同时把日志写到文件。这样一来用户既看不到黑框又能随时掌握进度。exe4j 本身解决的是怎么启动的问题而不见得每个程序都适合无脑选用 console 模式。6. JRE 分发与免安装 Java 环境的打包方案到这里exe 已经能生成了弹窗也能处理了控制台也按需显示了。但真正交付到客户手里之前还有最后一个绕不开的问题目标机器没有装 JRE 怎么办如果客户是一台全新电脑你没有远程桌面权限也没法帮他手动装 JDK那么把 exe 单独发过去他双击后十有八九就是找不到 JVM的提示。要解决这个问题最直接的办法是让 JRE 跟着 exe 一起走。6.1 从 JDK 精简出一个可用的运行时目录严格来说一个完整的 JRE 怎么获得最稳的方案是安装一个对应版本的 JDK然后在你的机器上运行jlink --add-modules java.base,java.desktop,java.logging,java.management,java.naming,java.sql,java.xml --output jrejlink是 JDK 9 之后自带的一个工具它可以根据你需要用到的模块裁剪出一个精简运行时。如果你的项目是一个 Spring Boot 后台服务需要的模块会稍微多一点但没关系jlink 会提示你缺哪个模块。裁剪出来的目录叫jre体积大概是完整 JDK 的一半左右。这个目录可以直接拷到目标机器也可以放进你的 exe 同目录发布。6.2 在 exe4j 中配置同级 jre 目录优先拿到裁剪后的jre目录后把整个目录复制到你输出的 exe 旁边比如MyTool/ ├── MyTool.exe └── jre/ ├── bin/ ├── conf/ └── lib/然后在 exe4j 的项目配置中JRE search那一页选择Advanced添加一个注册项路径留空exe4j 会理解为你希望搜索相对于 exe 目录的jre子目录。把这条搜索顺序调到最上面。之后重新生成 exe即使目标机器完全没有安装 Javaexe 也能从同目录的jre文件夹里找到运行时并启动你的程序。6.3 目录还是压缩包分发形态的建议如果你把 JRE 目录和 exe 放在一起打包成 zip客户拿到的还是一个压缩包需要自己解压再双击 exe。如果客户是比较普通的使用者我更推荐做一个简单的安装包可以用 Inno Setup也可以用 NSIS把MyTool.exe和jre目录整体塞进去。安装程序可以创建桌面快捷方式、添加卸载入口体验会好很多。还有一个小技巧Inno Setup 脚本中可以直接指定[Run]段让安装完成后自动启动程序这样客户装完马上就能看到界面。6.4 JRE 分发的法律与合规小提醒如果你使用的是 Oracle JDK注意它的商业使用条款对再分发有具体的规定OpenJDK 的发行版比如 Temurin、Zulu、Liberica普遍允许随应用一起分发。如果项目是商业用途建议用 OpenJDK 系的运行时避免授权上的麻烦。这里不展开讲法律问题但做商业软件交付前确认一下你用的 JDK 发行版是否允许再分发是一个必要的步骤。7. 一次完整的打包示例从 IDEA 项目到双击运行的 exe前面几章把原理、配置、常见问题都讲得差不多了。这一章我用一个实际的小工具作为例子完整走一遍流程方便你照着复现。以一个读取文本文件并统计行数的命令行小工具为例打包目标用的是控制台模式。7.1 项目准备与主类编写假设在 IDEA 中创建了一个普通 Java 项目主类代码如下import java.io.BufferedReader; import java.io.FileReader; public class LineCounter { public static void main(String[] args) { if (args.length 0) { System.out.println(Usage: LineCounter file path); return; } try (BufferedReader reader new BufferedReader(new FileReader(args[0]))) { int lines 0; while (reader.readLine() ! null) { lines; } System.out.println(Total lines: lines); } catch (Exception e) { System.err.println(Error: e.getMessage()); } } }这就是一个纯命令行程序编译后打包为可执行 jar。7.2 IDEA 中打包并验证按照第 2 章的步骤通过Project Structure-Artifacts生成 jar。打包完成后在 IDEA 底部终端执行java -jar out/artifacts/LineCounter_jar/LineCounter.jar如果没加参数程序会打印Usage提示加一个文本文件路径就能看到行数统计。确认这一步没问题后jar 包就是合格的。7.3 在 exe4j 里一步步配置打开 exe4j点击 Project type 选择JAR in EXEmode。接下来选择Console application因为我们需要在控制台看输出。在Executable name填LineCounter.exe输出目录设为D:\release。到Java invocation界面点击添加配置Main classLineCounterClasspath添加刚才的 jar 文件其余保持默认到JRE search页面添加本地 JDK 目录开发机验证阶段用。我这里指向C:\Program Files\Java\jdk-17。一路 Next点击Generate。此时D:\release下应该出现LineCounter.exe。打开 CMD切到该目录执行LineCounter.exe test.txt会看到控制台输出Total lines: N。这说明 exe 的 Java invocation 配置完全正确。7.4 这个过程里最容易搞错的 3 个操作我把这个示例跑过很多次之后总结出三个最容易搞错的地方第一Main class不能带包路径。如果项目里面有包名比如com.demo.LineCounter那就写完整的com.demo.LineCounter不带.java或.class后缀但如果没包名直接写LineCounter就行。第二Classpath里添加 jar 时如果 jar 路径带了空格比如D:\My Tools\LineCounter.jarexe4j 有时候会解析出问题。建议开发阶段把输出目录放在无空格的路径下等全部流程稳定了再移动到正式目录。第三Console 模式下如果程序一闪而过通常说明程序很快就执行完了。你看到的黑框一闪是正常现象如果想保留窗口便于查看输出可以在代码里加一句System.in.read()或者在 exe4j 的Additional Java parameters加上-Dconsole.encodingUTF-8再配合暂停逻辑。8. 高阶经验杀毒误报、打包体积与自动化构建回到最初的问题你已经成功做出了 exe接下来要面对的是如何持续、可靠地维护这个交付物。这里分享几个我踩过之后才总结出来的经验。8.1 关于杀毒软件误报的处理思路exe4j 生成的 exe 本质上是一个自解压启动器它会在临时目录释放文件并调用 JVM所以被杀毒软件标记为可疑的概率比普通 exe 高一些。如果客户那边报毒建议先确认不是你的程序真的带了恶意行为然后考虑这样几个步骤重新生成 exe避免每次生成的校验值不同导致反复报毒。尝试不加壳、不压缩保持 exe4j 的默认生成方式。如果是小范围内分发最有效的方法是把 exe 提交给目标机器所用的杀毒厂商做误报申诉。如果客户规模比较大我更建议把程序改成 jpackage 生成安装包因为安装包的数字签名机制对降低误报率有帮助。签发代码签名证书也能显著降低误报当然这是商业化的选择了。8.2 打包体积怎么瘦身exe4j 的 exe 本体通常只有几百 KB真正占空间的是你的 jar 和 JRE 目录。如果用户不能在目标机器安装 JRE你的发布包体积就会变成JRE 代码。要瘦身最有效的方法就是使用第 6 章的jlink生成精简运行时只保留你用到的模块。举个例子一个用 Swing 写的小工具完整 JRE 大概 300MB但通过 jlink 裁剪到java.base、java.desktop、java.logging等少数几个模块后可以压到 60MB 左右。如果项目里没有用到 Swing可能 40MB 左右就够用了。体积这东西能小一点客户下载时的体验就好一点。8.3 用命令行方式实现 exe4j 的自动化打包如果你的项目需要频繁更新版本每次都打开 exe4j 图形界面点一遍 Next 太浪费时间。exe4j 支持从命令行构建核心命令是exe4j.exe -project MyTool.exe4j只要你有.exe4j项目文件并且 IDE 构建出的 jar 文件更新了直接执行这一行命令就可以重新生成 exe。在 CI 上可以这样配置Maven 打包成功后调用 exe4j 的 exe 重新执行一次项目文件。这一套流程搭好之后整个发布过程就是一条命令的事不用再手动打开 GUI。8.4 更新日志与版本管理的实践最后讲一个工程化的小建议把 exe4j 的.exe4j项目配置文件放到 Git 仓库里和源代码一起管理。因为你会发现过了半年再回来维护这个项目时如果当时没保存配置文件你很可能已经忘了当初是怎么配置的得重新拖一个项目非常痛苦。另外exe4j 配置文件是明文 XML你可以用文本对比工具查看历史版本之间到底改了什么比如 JRE 搜索路径变了、图标换了一目了然。这算是这个工具被很多人低估的一个优点。我在实际使用中还有一个习惯每次重新生成 exe 后都会在计算文件哈希值把这个值记录到发布说明里。这样客户遇到问题时第一件事就是对比哈希值可以快速判断他手上的 exe 是不是你最新发的版本省掉很多来回沟通的成本。如果把 exe4j 的打包做成一条标准流水线你后续每次发版只需要三步更新代码、执行打包脚本Maven/Gradle 构建 exe4j 命令行、上传到分发平台。剩下的时间可以多去打磨产品本身而不是反复折腾怎么又弹错这种问题。