Launch4j实战：Java应用打包成Windows双击EXE的完整指南

Launch4j这个工具我断断续续用了大概七八年。最早接触是在给单位做一个内部台账小工具的时候好不容易把功能写完结果同事一句怎么双击打不开直接把我说懵了——后来才明白不是程序有问题是对方电脑上压根没装Java。这种事经历几次就知道Java桌面应用在Windows下的最后一百米有多重要。这篇文章就是聊聊怎么用Launch4j把JAR包变成双击就能跑的EXE以及这七八年时间里踩过的各种坑、总结出的经验。内容我尽量写得实际操作一些适合做内部工具、个人小项目和轻量分发的场景。如果你想用Java写点东西丢给Windows用户用又不想强迫人家安装JDK或者背一箩筐环境变量配置这篇应该对你有用。我会先从最核心的问题聊起——为什么Java应用非要套个壳然后讲工具选型再拆解Launch4j的配置逻辑最后是完整的实际操作流程和避坑经验。1. 为什么Java桌面应用需要一个壳1.1 直接发JAR包的尴尬先说个最基础的现实。JAR包本质上是一个zip压缩文件只不过里面的内容遵循Java的规范。要让别人运行它通常只有两种方式双击需要系统里有正确的文件关联或者命令行输入java -jar xxx.jar需要PATH里有java命令。这两种方式在开发机上都没问题因为你装了JDKIDE也帮你配好了环境。但一旦把JAR发给普通用户——特别是那种电脑里只有微信、WPS、爱奇艺的用户——问题一下就出来了用户双击JAR系统弹出选择打开方式对话框一脸懵用户手动装了个JDK但环境变量没配好java命令找不着就算环境配好了也可能出现版本不匹配比如你用Java 17新特性写的代码对方装的是Java 8直接报UnsupportedClassVersionErrorJAR双击后有时会有一个黑色的cmd窗口一闪而过用户根本看不到报错信息只会觉得程序坏了。这些问题的本质是你交付的是半成品运行环境需要使用者自己搞定。而正确的交付方式是给用户一个独立的EXE双击打开用不用JRE是程序自己的事用户不需要知道底层细节。1.2 壳给用户和开发者带来的价值Launch4j做的事情就是给JAR做一层Windows下的壳——一个原生EXE启动器。它的运行逻辑大致是这样的用户双击EXE后启动器检查本机是否有符合条件的Java运行时找到后就启动对应的JVM并加载你的JAR找不到就弹出提示或者走你设定的兜底逻辑。这个过程对用户是完全透明的。带来的直接好处有用户不需要手动安装JDK/JRE或者即使需要也能通过你设定的方式去获取EXE以原生进程方式运行在任务管理器里能看到清晰的进程名而不是一长串java.exe可以配置图标、版本信息、公司名看起来像一个正经的Windows应用支持文件关联、启动参数透传、JVM选项定制等能力。这里要澄清一个概念戴上一个壳并不改变JVM的运行机制。程序跑起来之后底层还是Java进程字节码还是在JVM里解释执行。壳并不是把Java代码编译成原生机器码它只是一个引导器。这一点经常有人误解以为用了Launch4j就有了原生应用一样的启动速度和性能——不存在的。启动速度取决于JVM的加载速度而不是壳本身。1.3 什么样的场景适合壳方案用Launch4j这类工具适合的是这些场景内部工具、管理脚本的图形化前端比如一个连接数据库做数据清洗的小界面给非技术同事、客户分发的桌面小应用比如合同台账、批量改文件名的工具需要自定义图标、版本信息和Windows集成特性的Java应用希望在最小改动下把现有JAR交付成EXE的遗留项目。不太适合的场景是对启动速度有极致要求的单文件应用或者希望完全脱离JVM的软件。这类需求更适合考虑GraalVM Native Image或者jpackage配合jlink产出自带运行时的小型镜像。如果你只是想让Java程序在Windows上像样地跑起来Launch4j这个级别的壳就够用。2. 主流打包工具横评为什么选择Launch4j2.1 业界常用的几种方案Java应用打包成Windows可执行文件市面上大致有这几类思路。我实际都用过简单说说各自的定位。工具/方案授权方式核心能力典型不足exe4j商业收费启动器、服务模式、自定义画面配置项太多上手成本高收费jpackageJDK官方能生成EXE/MSI可配合jlink裁剪运行时打包体积大交叉构建麻烦WinSW开源把Java程序包装成Windows服务只面向后台服务不做桌面应用批处理/自解压无解压JRE和JAR再运行没有原生图标容易被杀软误报Launch4j开源免费轻量启动器支持JRE搜索和捆绑不做安装包单文件或多文件分发需搭配其他工具这些工具我基本都试过。exe4j功能确实全但那个界面密密麻麻的选项每次打开都像在做阅读理解而且收费license对个人开发者不友好。jpackage是官方方案Java 14之后的版本能用不过在实际项目中它的构建过程比较重特别是你想在Linux的CI上交叉编译出Windows的EXE或者MSI会比较折腾。WinSW我用了大概半年它的定位很纯粹——服务场景很棒我之前写过一篇用WinSW把Java程序做成Windows服务的内容但这不是同一个问题。如果你要做的是有界面的桌面应用WinSW帮不上忙。2.2 Launch4j的优劣势分析站在多年使用的角度我觉得Launch4j最大的优点是轻和直接。配置文件就是一个XML十几行就能完成基本打包。没有复杂的安装包向导也没有一堆你根本用不到的选项。它生成的核心产物就是一个EXE加上可选的配套JRE目录整个交付物非常透明。而且它是纯Java实现的工具GUI是Swing写的在Windows、Linux、macOS都能运行而且生成Windows的EXE。这对在Linux CI服务器上做交叉打包特别友好——你不需要一台Windows机器就能产出Windows可执行文件这个特性在自动化发布流程里非常实用。缺点也明显它不会优化你的代码或者裁剪运行时只是加壳不能像jlink那样按需裁剪模块所以如果你的需求是尽量减小分发体积它帮不上太多开源项目没有商业支持遇到问题基本靠GitHub issues和自己摸索对Windows Installer/MSI这类安装包格式没有支持如果要给用户做完整安装引导需要另配Inno Setup等工具界面看起来比较上古时代图标资源管理和版本信息编辑都不是很顺手。2.3 我可以给出的选择建议如果你的目标用户是一群Windows小白项目本身结构简单、依赖也不多Launch4j完全够用。如果你需要的是安装包、自动更新、卸载程序这些完整分发体验有两个方向一是用jpackage直接生成安装包二是用Launch4j生成的EXE配合Inno Setup做安装器。我自己目前的组合是Launch4j Inno Setup。为什么不用jpackage全包因为jpackage生成的安装包在每次版本更新时安装向导的交互逻辑需要保持一致同时它对国内一些软件管理器的兼容性不如传统Inno Setup生成的安装程序。当然这有点个人偏好jpackage也是官方正路。总之Launch4j这层启动器角色在目前的主流方案里仍然有不可替代的位置。3. Launch4j核心配置逐项拆解3.1 最小可用配置长什么样Launch4j有两种操作方式GUI填表后生成XML或者直接写XML再交给命令行程序处理。我第一次用它就是GUI填几项点一下构建就成了但后来发现还是XML可维护性高——因为一个项目每次发版都要重新构建手填GUI既慢又容易漏。所以我建议一开始就熟悉XML结构把配置纳入版本管理。一份最简配置大致是这样的launch4jConfig dontWrapJarfalse/dontWrapJar headerTypegui/headerType jarapp.jar/jar outfileapp.exe/outfile errTitle应用启动失败/errTitle jre pathjre/path minVersion1.8.0/minVersion maxVersion17/maxVersion /jre versionInfo fileVersion1.0.0.0/fileVersion productVersion1.0.0.0/productVersion companyName我的公司/companyName productName台账工具/productName fileDescription内部台账管理工具/fileDescription copyright© 2024/copyright /versionInfo /launch4jConfig这里有个核心配置要先理解清楚dontWrapJar。这个配置决定了JAR是被嵌进EXE里面还是保持外部JAR文件。默认false表示把JAR包装进EXE好处是最终只有一个文件用户不会误删JAR坏处是每次改代码都要重新生成EXE而且如果JAR很大比如几十MBEXE的启动加载会稍慢。如果选trueJAR就放在EXE旁边EXE只是作为启动器寻找同目录下的JAR。我个人的习惯是小工具5MB以内的JAR用false一个文件发出去干净利落项目较大或者代码改动频繁的用true省得每次都重新打包EXE。另外如果你的程序会被杀毒软件盯上保持外部JAR也有助于降低误报率——因为它不像是从EXE里释放代码再运行的行为。3.2 JRE搜索逻辑这是配置里最重要的部分Launch4j默认不会帮你携带JRE它会在目标机器上搜索可用的Java运行时。这个搜索顺序是固定的理解它对于排查为什么用户机器打不开至关重要。官方文档给出的搜索顺序大致是如果在配置里指定了捆绑JRE即jre里的path字段优先使用它尝试使用静态注册的JRE路径比如某些安装程序写入了注册表项扫描注册表里已安装的JDK/JRE版本匹配minVersion和maxVersion尝试JAVA_HOME环境变量尝试PATH中的java命令还是不行就会弹出错误对话框提示找不到JRE。看到这里你应该明白了配置里jre的path字段如果填了一个相对路径比如jreLaunch4j会在EXE所在目录下找这个jre子目录找不到就往下走注册表和环境变量。也就是说你不一定要捆绑JRE但要保证目标机器上至少有一个版本符合条件的Java运行时。minVersion和maxVersion用于限定版本范围。minVersion很有用比如你的代码用了Java 8的Lambda就设置minVersion为1.8.0。maxVersion要谨慎一般建议要么不设要么设一个较大的上限。为什么因为用户机器上可能装了Java 21而你的程序其实兼容Java 8到17不设maxVersion反而兼容面更广。除非你明确知道自己的代码在某些新版本上有问题否则不要轻易设上限——我就见过有人设了maxVersion为17结果用户机器上只装了Java 21程序直接启动不了只因为多个版本号的好心限制。3.3 图标、版本信息和启动行为配置图标是窗口和任务栏显示的图片Launch4j只支持ICO格式的图标文件。这里有个常见误区直接把PNG改后缀名为.ico或者用一个尺寸很小的ICO就完事了。Windows图标资源的最佳实践是包含多种尺寸16x16、32x32、48x48、256x256等的ICO文件这样在任务栏、资源管理器不同缩放级别下都能清晰显示。你可以在网上找在线转换工具生成多尺寸ICO或者用ImageMagick处理命令行如下magick convert icon_1024.png -define icon:auto-resize256,48,32,16 app.ico版本信息在文件的属性-详细信息里展示包括文件版本、产品版本、公司名、版权等。这里的版本号格式是四个数字段比如1.0.0.0Windows用这个做版本对比。注意版本号不能出现中文或特殊符号否则Windows资源管理器会显示不了。启动行为里值得留意的配置是manifest和dpiAware。manifest可以指定以管理员权限运行比如程序需要写C盘Program Files下的配置文件以及操作系统版本兼容性声明。dpiAware设为true可以避免高分屏下字体模糊。这两个配置如果缺失在高DPI屏幕或者需要管理员权限的目录操作时你会遇到一些看似莫名其妙的界面问题。3.4 内存、启动参数与JVM选项启动器另一个实用功能是配置JVM参数。常见的写法jre pathjre/path minVersion1.8.0/minVersion jvmOptions opt-Xmx512m/opt opt-Dfile.encodingUTF-8/opt /jvmOptions initialHeapSize128/initialHeapSize maxHeapSize512/maxHeapSize /jre这里initialHeapSize和maxHeapSize单位是MB对应JVM的-Xms和-Xmx。如果程序是内存敏感型比如加载大数据文件或大量图片记得给足maxHeapSize。但如果是运行在内存较小的办公电脑上给一个过大的值反而容易启动失败而且还可能导致用户的电脑卡顿。稳妥做法是初始128MB、最大512MB到1024MB之间具体数值根据自己的程序实测来定。还要注意JVM参数和程序参数的区分。jvmOptions是给JVM的比如-Xmx、-D系统属性这类程序自己的参数也就是main方法接收的String[] args应该在Java代码里通过启动器额外参数或者运行时命令行传入。写代码时可以用System.getProperty读取-D配置用main函数入参读取外部参数。这样和启动器配合起来更灵活。4. 实战打包从JAR到EXE的全流程4.1 准备工作项目与JAR的构建在用Launch4j之前先把Java项目构建成可执行的JAR包。如果是Maven项目在pom.xml里加上maven-jar-plugin配置Main-Class或者用spring-boot-maven-plugin打成Fat JAR。以普通Maven项目为例plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version3.4.1/version configuration archive manifest mainClasscom.example.Main/mainClass /manifest /archive /configuration /plugin如果是Spring Boot项目直接mvn clean package生成的JAR就是可执行的但要注意Spring Boot的JAR结构比较特殊BOOT-INF目录Launch4j的dontWrapJarfalse机制能不能正确处理实话说是可以的因为启动器最终是通过java -jar方式加载JAR并不关心JAR内部结构。不过如果把这种Fat JAR嵌进EXEEXE的体积会明显变大启动时的解压逻辑也会多耗一点时间。所以Spring Boot项目我更推荐dontWrapJartrue让JAR作为外部文件保持清晰。4.2 使用GUI工具构建从Launch4j官方GitHub Releases或官网下载对应版本。Windows版自带launch4j.exe这个GUI程序同时也有launch4jc这两个命令行程序。打开GUI后界面分几个Tab基本配置、JRE配置、图标/版本、启动界面等。基本配置里填JAR路径、输出EXE路径、是否包装JAR。JRE配置里填版本范围和JVM参数。图标与版本里加载ICO填写版本信息。都填好后点右上角的构建按钮会生成一个EXE文件。GUI适合第一次尝试和快速验证而且它也会生成一份XML配置文件。我建议你点一下保存配置把它存下来。这样下一次发版直接改版本号用命令行重新构建就完了不用再开GUI。XML配置跟着项目走也方便团队成员各自打包。4.3 使用命令行和XML构建命令行构建的核心是launch4jc这个程序它接收两个参数--config xxx.xml。在Windows上launch4jc.exe --config app.xml在Linux CI上/opt/launch4j/launch4jc --config app.xml注意launch4jc在Linux上是一个shell脚本在某些系统上可能需要先赋予执行权限。另外如果你的launch4jc脚本指向了GUI程序在无显示器环境下会出现无法打开display这类报错。要确认你使用的是真正的命令行程序而不是GUI版。Linux下无头环境跑GUI版是我踩过的坑简单说就是头文件路径问题我们后面再细聊。4.4 验证打包结果的关键点打包完成后不要急着发出去。先按这个清单验证一下双击EXE确认程序能正常启动窗口标题、图标正确打开任务管理器看进程名是否是app.exe而不是java.exe这能确认启动器用的是原生壳而不是绕开了壳打开CMD输入app.exe --version这样的参数确认参数能透传到主程序main方法在没有安装Java的机器或者临时禁用了系统JRE环境变量上测试确认JRE搜索逻辑符合预期检查EXE的属性菜单确认版本信息、文件描述、公司名都填上了。其中在没有Java的机器上测试这一点怎么强调都不为过。你可以用一台干净的Windows虚拟机装好后什么Java环境变量都不配然后直接跑EXE。如果程序在这种环境下能正常起来说明你的JRE捆绑或搜索策略是有效的。4.5 一种更稳的分发方式捆绑JRE如果目标用户是彻底的小白注册表搜索、环境变量这些都指望不上最稳妥的方案是把一个精简过的JRE放在EXE旁边并在配置里指定path指向它。怎么获得精简JRE用jlink命令jlink --module-path $JAVA_HOME/jmods --add-modules java.base,java.desktop,java.sql --output jre --strip-debug --no-header-files --no-man-pages这样生成的jre目录通常只有40MB左右具体取决于你保留的模块。比如一个只做数据库管理和文件处理的小工具保留java.base、java.desktop、java.sql基本就够了。然后把EXE、JAR如果用dontWrapJartrue和jre目录放在同一个文件夹里整个文件夹一起发给用户。用户双击EXELaunch4j在EXE同级目录找到jre直接使用完全不需要用户手动安装Java。这种EXE jre目录 可选JAR的形态自己打包、自己分发、自己控制运行时版本是日常交付桌面小工具最实用的方式。缺点只是体积稍微大了一点但换来的是用户零配置这个交换非常划算。我在内网环境下给非技术同事分发工具基本都是这种形式。5. 踩坑实录图标、JRE搜索与路径问题5.1 图标不显示原来不是Launch4j的问题有一次我给工具换了新图标重新构建EXE后发给同事对方说怎么还是旧图标。我本地怎么看都是新的反复对比了文件md5也没问题后来发现不是图标没进去而是Windows的图标缓存。Windows Explorer会缓存EXE的图标尤其在文件没有彻底修改文件指纹的时候。让同事刷新缩略图缓存或者重命名文件图标就正常了。最简单的验证方法是把EXE复制到另一个目录再看如果新目录里图标是新的那就是缓存问题。另一个坑是ICO格式的兼容性。有些在线转换工具生成的ICO只有单一尺寸在某些Windows版本或者缩放下会模糊或干脆不显示。所以在生成ICO时注意多尺寸同时检查分辨率避免用从PNG直接改扩展名得来的假ICO。用ImageMagick转换是最省心的前面提过的命令生成的多尺寸ICO实测在Windows 10/11上表现正常。5.2 找不到JRE的经典报错与排查链路最常见的用户报错就是双击EXE弹出Failed to find Java Development Kit之类的对话框。这个提示的英文是Launch4j默认带的很多初学者直接把默认错误提示发给了用户结果就是等了好久用户才反馈打不开有一个英文弹窗。排查这类问题我建议按这个顺序来先看EXE旁边的jre目录是否存在是否和配置里的path字段对应检查目标机器上是否有符合版本范围的Java运行时用命令行执行java -version确认实际版本确认JAVA_HOME环境变量有没有被设置成异常值比如指向了一个不存在或者版本过低的路径打开注册表编辑器查看HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment下的版本记录是否正常用Launch4j的日志功能或者自定义errTitle让错误的细节对用户可见。还有一个容易忽略的点有些杀毒软件会拦截或静默删除Launch4j生成的EXE因为它本质是一个从EXE里释放JAR到临时目录再运行的程序——这个行为特征和某些恶意软件非常相似。如果用户环境里的安全软件管得严建议加白名单或者想办法做代码签名。没有代码签名证书的情况下这也是我倾向于用dontWrapJartrue、保持外部JAR的一个原因。5.3 相对路径的坑怎么都绕不过去Launch4j生成的EXE工作目录默认是用户双击EXE时所在的目录而不是EXE所在目录。这一点是很多人踩坑的重灾区。举个例子程序里用new File(config.properties)读取配置用户从桌面快捷方式启动工作目录就是桌面而不是你安装程序的目录自然读不到config.properties程序就崩了。解决方案有几种在程序里通过定位自身JAR或者Class.getProtectionDomain().getCodeSource()来推断程序根目录进而拼接配置路径使用System.getProperty(user.dir)获取当前工作目录但要小心这个值在不同启动方式下会变在Launch4j的XML配置里设置workingDirectory字段指定程序的工作目录为EXE所在目录。我的建议是在代码里做根目录定位不要依赖外壳。因为Launch4j只是在启动时解析路径真正运行时的当前目录由Windows决定这个坑不是一个配置能完全解决的。自己在代码里处理才是根本办法。具体来说就是拿到JAR文件所在的绝对路径然后用这个绝对路径去拼配置文件的位置。5.4 中文路径与空格这些小问题很伤人还有一个多语言环境下的隐藏坑程序路径里有中文或空格。Launch4j生成的EXE一般能应对但如果你在配置里写了硬编码的相对路径或者JAR路径用的是绝对路径可能出问题。例如把工具放在C:\Users\张三\我的工具\下某些第三方库和旧版JVM在读路径时编码不一致就可能抛出FileNotFoundException或者ClassNotFoundException。稳妥做法是开发时就用相对路径发布时把EXE、JAR、jre放在同一个目录不依赖系统任何绝对路径。同时建议在配置文件中避免含中文目录的硬编码。用户机器上如果有中文用户名Windows用户目录本身就是中文的所以代码和脚本尽量不要写死路径而是用动态定位。你要是在目标用户电脑上部署最好提前确认一下他的用户目录名是中文还是英文——这决定了你会不会踩这个坑。6. 进阶玩法命令行批处理与CI集成6.1 每次发版都手动点GUI没必要一旦你的项目开始频繁发版手动开GUI改版本号、点构建、复制文件这一整套流程就会很痛苦。把Launch4j集成进构建脚本我自己的做法是先写一个打包脚本然后和Maven/Gradle生命周期绑定。写一个pack.shWindows下就是pack.bat内容大致如下#!/bin/bash /opt/launch4j/launch4jc --config config.xml然后把这个脚本接入Maven的exec-maven-plugin在package阶段自动调用plugin groupIdorg.codehaus.mojo/groupId artifactIdexec-maven-plugin/artifactId version3.1.0/version executions execution idlaunch4j-package/id phasepackage/phase goals goalexec/goal /goals configuration executablelaunch4jc/executable arguments argument--config/argument argument${project.basedir}/packaging/launch4j.xml/argument /arguments /configuration /execution /executions /plugin这里有个细节exec-maven-plugin执行时executable的路径需要在PATH里能找到或者写成绝对路径。相对路径在某些CI上会因为工作目录不同而失效最好用${project.basedir}拼一个完整路径。另外一个更Maven原生的做法是直接用com.akathist.maven.plugins.launch4j插件它封装了Launch4j的调用用法更简洁不过需要插件仓库里能找到对应版本。6.2 在GitHub Actions里自动打包如果项目托管在GitHub上可以在workflow里加一个job专门做Windows EXE的构建。因为Launch4j是Java工具Linux环境就能跑交叉构建非常方便jobs: build-exe: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-javav4 with: distribution: temurin java-version: 17 - run: mvn -B package - name: Run launch4j run: | wget -q -O launch4j.tar.gz https://github.com/launch4j/launch4j/releases/download/3.50/launch4j-3.50-linux-x64.tgz tar xzf launch4j.tar.gz ./launch4j/launch4jc --config packaging/launch4j.xml - uses: actions/upload-artifactv4 with: name: app-windows path: target/app.exe注意下载Launch4j的URL要锁定你验证过的版本号不要用latest动态链接。我在CI里踩过的坑一个是网络源不稳定导致拉取失败另一个是解压后的目录结构和文档不完全一致。解决办法就是先把工具链在本地跑通再把同样的命令原样搬进workflow不要想当然。6.3 用变量模板管理版本号Launch4j的XML配置文件里versionInfo字段建议用占位符比如${project.version}在构建脚本里通过sed替换成真实版本。这些都是构建脚本的常规操作但是能让发版流程规范很多。我这里给一个简单的思路维护一份launch4j-template.xml里面把版本号和产物名写成占位符fileVersionVERSION.0/fileVersion productVersionVERSION.0/productVersion outfileAPP_NAME.exe/outfile然后在打包脚本里做替换sed -i s/VERSION/$VERSION/g; s/APP_NAME/$APP_NAME/g launch4j-final.xml整个流程就是一条命令mvn clean package脚本自动完成JAR构建、Launch4j打包、生成EXE、发布到内部文件服务器。省去了大量手工操作也杜绝了忘了更新版本号这种低级错误。6.4 启动器分发的最后一道细节错误提示与日志最后说一个容易被忽略但很重要的细节错误提示。当目标机器找不到JRE、或者JAR缺失的时候Launch4j默认的错误对话框往往只有一行英文提示用户看了毫无头绪。配置里有一个errTitle字段可以自定义标题栏文字正文则可以用自定义消息模板。更实用的做法是结合日志。可以在配置里打开日志功能让启动器把启动过程和错误信息写入EXE同目录下的日志文件。对技术人员排查问题非常有用。我自己一般是开发环境开日志发布时关闭避免用户目录被日志文件污染。6.5 和其他工具的组合Inno Setup Launch4j前面提过一次的经典组合这里展开说说。Launch4j生成EXE后再用Inno Setup写一个安装脚本把EXE、JAR、jre目录、配置文件一起打包成Setup.exe。安装过程中Inno Setup负责创建桌面快捷方式、写注册表卸载信息、设置安装目录。用户得到一个完整的安装体验。Inno Setup的脚本不算复杂核心就是定义Source文件和任务[Files] Source: target\app.exe; DestDir: {app} Source: target\jre\*; DestDir: {app}\jre; Flags: recursesubdirs Source: target\app.jar; DestDir: {app} [Icons] Name: {group}\台账工具; Filename: {app}\app.exe这个组合的好处是Launch4j解决怎么启动Inno Setup解决怎么安装各司其职比单一工具单打独斗效果更好。安装包做出来后用户只需要一路Next装完桌面就有快捷方式卸载也能从控制面板走。我目前的对外发布流程都是这个组合实测用户接受度非常高。最后想分享一个个人体会打包工具这种东西最重要的不是功能多齐全而是你要完全理解它每一步在做什么。Launch4j的XML配置其实不复杂但JRE搜索顺序、工作目录、dontWrapJar这些概念如果只是照着网上教程填一遍很可能在某个用户那里突然翻车。多花点时间在启动器和JRE的关系上比什么都值。以后你每做一个Java桌面工具这层壳就不会再成为交付路上的阻碍了。