简介：JD-GUI 1.4 官方MAC版本是面向macOS开发者的Java反编译工具，通过图形化界面直接查看.class字节码对应的源码，适用于软件逆向分析、调试及学习Java程序内部实现。资源包含14个文件，压缩包7.53MB，内部有JD-GUI.app主程序、Resources资源目录、Info.plist配置及MacOS启动脚本等，双击.app即可运行，已有1036人下载学习。包内的jar、sh、plist、icns等文件分别对应核心逻辑、启动辅助、属性配置和应用图标，目录结构保留了macOS标准布局，方便理解各组件用途。借助拖拽加载与搜索定位，可快速浏览类结构和方法逻辑；对于没有源码的第三方库或混淆类，反编译结果仍能提供关键调用关系，帮助排查问题；在阅读框架源码或排查第三方库问题时，能大幅节省时间。通过JDI与JVM API解析类文件指令还原可读源码，无需联网、离线可用，是macOS环境下轻量实用的Java代码分析利器。
1. JD-GUI 1.4 官方MAC版本：老JAR清理工具为什么至今还有人找
上周帮人接手一个遗留系统，codebase 里躺着一个五六年前的依赖 JAR，没有源码，IDE 里跳转不过去，打开 class 全是一堆0xCAFEBABE。翻出 JD-GUI 1.4，三分钟就把几十个类的逻辑读出来了，注释里的中文还完整保留。这就是很多人还在找官方 MAC 版的原因：它轻量、免安装、不联网，把一个 class 文件变成可以阅读和导出的 Java 源码。它解决的是没有源码时的审阅、排障、学习需求，适合经常要钻进编译产物里找魔法的开发者，尤其是那些不想为了一个工具去适配新版 IDEL 的 Mac 用户。1.4 这个版本虽然老，但干净、稳定，命令行参数也简单，直到今天仍然是桌面端反编译里最顺手的一把刀。
2. 下载与安装：确认官方MAC版本再到启动，只差两个命令
2.1 下载资源怎么验真：哈希校验与文件结构
拿到任何一个标着官方 MAC 版本的 JD-GUI 1.4 资源，我建议先别急着双击。第一步是验哈希，别信文件名，别信压缩包里的截图，尤其不要从那种满屏“破解版”“绿色版”的站点拿东西，被塞广告脚本是常态。我一般会把下载包放进临时目录，打开 macOS 自带的终端，跑两个命令：
shasum -a 256 "JD-GUI-1.4.0.dmg" file "JD-GUI-1.4.0.dmg"shasum计算文件的 SHA-256，输出一串 64 位十六进制字符；file直接读取文件头的真实格式。如果你能找到官方发布页提供的哈希值，就逐位比对。哪怕找不到哈希值，至少用file看真身：一个 MAC 版 DMG 应该输出类似Apple Disk Image或zlib compressed data，如果输出的是Windows PE executable那就是拿错包了。这一步花不到一分钟，却能在后续闪退排查时帮你排除“资源本身被改过”这个变量。
验完哈希再解压，观察目录结构。官方版本通常是一个.app包，也有的打包成纯 JAR 形式。.app包的内部是标准的Contents/MacOS可执行文件，可以右键显示包内容来检查。如果你看到一堆奇怪的setup.command或者.bat文件，直接扔掉。哈希校验和心理预期都对齐后，再谈启动。
2.2 启动方式：DMG 拖拽与 JAR 命令两条路
分两种情况。如果你拿到的是.dmg或.app，双击挂载后把JD-GUI.app拖进 Applications 目录。第一次启动会遇到 macOS 的 Gatekeeper 提醒，因为 JD-GUI 1.4 没有做现代签名，右键点图标，选“打开”，再点一次“打开”，就能绕过网络的单次限制。如果你拿到的是 JAR 文件，终端执行：
java -jar jd-gui-1.4.0.jar这种方式的优点在于启动日志全部打在终端里。如果哪次 UI 起不来，终端会先抛异常，比如UnsupportedClassVersionError或者AWTError，比双击.app后闪退黑匣子式排障要直观得多。我一般会把 JAR 版本一直留着，哪怕已经有了.app，遇到诡异问题也从 JAR 启动看日志。
需要特别说明的是，JD-GUI 1.4 的官方 MAC 版并不需要安装任何服务，也不需要把 JAR 放在固定位置。你可以把它丢在/opt/tools或者一个工作目录里，每次用终端启动。如果想偷懒，写一个 alias 是后话，第 4 章再展开。
2.3 确认 Java 环境：JDK 版本和位数的边界
JD-GUI 1.4 是 Java 8 时代的产物，虽然理论上有 Java 1.8 以上的环境就能跑，但现代 Mac 上多版本 JDK 并存的问题经常出现。我是先跑：
java -version看到输出里的java version "17"或"21"，并不意味着一定不行，但如果启动时报模块化异常，比如InaccessibleObjectException，那就是 JDK 版本太新对旧库的限制。最稳妥的组合是 JDK 8 或 JDK 11，尤其是你打算用 AppleScript 自动化把它当日常工具时。多版本环境下，可以用：
/usr/libexec/java_home -V它会把本机所有 JDK 版本列出来，然后指定某个版本启动：
/usr/libexec/java_home -v 11 --exec java -jar jd-gui-1.4.0.jar这条命令先让java_home定位 JDK 11，再把定位到的java可执行文件传给后续参数。注意-exec后面的java不是java_home，而是位于$JAVA_HOME/bin下的那个，它会把后面的-jar原样接收。从这里就能看出，JD-GUI 1.4 的启动边界其实就是 Java 环境的边界，提前把 Java 版本固化好，后面所有使用环节才不会出现版本玄学。
3. 反编译操作实战：从打开 JAR 到导出全部源码
3.1 用 GUI 打开 JAR：目录结构与代码区导航
把 JAR 拖进 JD-GUI 窗口，或者用菜单File -> Open File...，快捷键是 Command+O。界面左侧是包树，右侧是源码区。这里的包树和 IDE 的 Project 面板很像，但有一个区别：除了正常的 com/xx/yy 包，它会把编译生成的内部类直接显示成Foo$1.class、Foo$Inner.class这样的节点。刚开始我不理解为什么有这么多带美元符号的类，以为是源码污染，后来才意识到这些就是匿名内部类经过 javac 处理后留下的真实名称。
点中任意一个类，右侧立刻显示反编译后的 Java 代码。顶部有类所在的完整包路径，中间是源码，底部状态栏会显示当前类的行数和字节大小。如果你要跳转某个类，Command+O 除了能打开 JAR 文件，在打开 JAR 之后的文件选择里并不支持类搜索，但 JD-GUI 主界面顶部有一个搜索框，输入类名能里快速过滤，用熟之后比一层层点包树高效得多。
注意右键菜单里有一个View Bytecode选项，点开之后会显示该类的 JVM 字节码。这个功能在 1.4 版本里非常实用，当反编译源码出现明显错误时，切出来看字节码，能帮你确认真实执行逻辑。很多新人不看这个视图，只看反编译结果，导致误判，熟手一定会在源码和 Bytecode 视图之间来回切。
3.2 保存全部源码：导出格式与包结构
当你需要把整个 JAR 变成工程目录时，用菜单File -> Save All Sources...。选择输出目录，JD-GUI 会自动按包结构创建文件夹，每个类对应一个.java文件。还会额外导出所有资源文件，比如.properties、.xml、图片，这些会被分到一个叫resources的目录里。这么做有个好处：你可以直接把导出目录丢到 IDE 里作为项目源码树，资源文件也不丢。
保存时有两个参数需要留意。第一是输出路径不要放在原始 JAR 所在的同一目录里，我见过有人直接保存并覆盖原工程，结果把源码和 class 混在一起，导致 IDE 编译时出现重复类定义。第二是文件名冲突，某些 JAR 内部有两个包路径不同但类名相同的类，JD-GUI 会用Name.class的方式保留内部类后缀，导出的文件里会出现Foo$1.java这种古怪的名字。这是正常现象，不要手工重命名，否则包结构对不上。
右键单个类时还会有Save Source的选项，只保存当前一个类的源码。这个功能适合只想引用某几个类时使用，但要注意：如果你保存了内部类Foo$1.java，而它引用了外部类Foo，单独拿出去编译是不会通过的，因为外部类源码没有一起保存。所以大批量审阅时，尽量用 Save All Sources，而不是逐类保存。
3.3 反编译参数边界：方法签名、泛型与枚举
JD-GUI 1.4 使用的反编译引擎在 Java 8 的 class 文件处理上问题不大，但并不是无脑还原。第一个边界是泛型擦除，字节码里的泛型签名只在调试信息里存在，如果 JAR 编译时没有加-g参数，反编译器就只能看到原始类型Object，导出的源码会变成List list而不是List<String>。第二个边界是枚举，反编译之后枚举的values()方法通常会生成为一个数组，然后复制出values,valueOf,$VALUES三个部分，看起来非常别扭，因为这是编译器的真实结构，不是源码原貌。
第三个边界在 lambda。如果一个类用了 lambda 表达式，且编译目标是 JDK 8，反编译结果里会多出一个合成类Foo$$Lambda$1，它通过invokedynamic引导调用真正的实现。JD-GUI 1.4 不会自动把Foo$$Lambda$1还原成 lambda 的样子，而是展示成一个单独的类。这种情况下，你反编译出的代码虽然逻辑正确，但风格和原有的工程差异巨大，不能指望它直接可编译。遇到这些边界，正确姿势是用javap -p -c对照方法体，把缺失的泛型和 lambda 手动补全，或者直接放弃还原，只在 JD-GUI 里阅读逻辑。把反编译工具当成“只看不改”的辅助，比强行要求它输出可编译源码要实用得多。
4. 命令行与批量处理：JD-GUI 1.4 的隐藏启动参数
4.1 启动时直接传入 JAR 路径
很多人只把 JD-GUI 当成一个双击打开的图形工具，其实它支持启动时传入文件参数。命令行：
java -jar jd-gui-1.4.0.jar /path/to/your.jar如果路径带空格，必须加引号：
java -jar jd-gui-1.4.0.jar "/path/to/my project/libs/target.jar"这种启动方式等价于打开 GUI 后手动点击打开文件，能省一次点击，更重要的是为后续批量脚本提供基础。不过它只认第一个 JAR 参数，后面的不会全部打开，需要一次开多个 JAR 时，用脚本批量启动更合适。
4.2 用 AppleScript 脚本批量打开多个 JAR
JD-GUI 1.4 没有官方的 CLI 批量导出命令，但有一个很实用的折中方案：写一个 bash 循环，每次启动一个 JD-GUI 实例并传入不同 JAR。我一般会在临时目录里执行：
for j in /path/to/libs/*.jar; do java -jar /path/to/jd-gui-1.4.0.jar "$j" & done&让每个进程后台运行，同时打开多个窗口。执行前先echo "$j"看一眼路径是否正常，避免因路径意外带通配符导致启动失败。这个方案的缺点是每个窗口都会维护一套完整的索引，内存占用成倍上涨。经验上 3 到 4 个 JAR 同时在界面上还能接受，再多就会明显卡顿。建议一次不要超过 4 个，如果超过 4 个，改成按顺序处理：先打开第一个，看完导出，关掉再开下一个。也可以用一个带sleep的循环控制节奏：
for j in /path/to/libs/*.jar; do java -jar /path/to/jd-gui-1.4.0.jar "$j" sleep 3 done这样每次在前一个窗口关闭后才执行下一个，缺点是等待时间不可控，甚至会出现前一个你没看完它就启动下一个。根据自己的使用习惯选择即可。
4.3 设置内存参数与系统属性
大型 JAR 在解析时经常把默认堆内存占满，启动参数可以手动加大：
java -Xms512m -Xmx2g -jar jd-gui-1.4.0.jar "/path/to/large.jar"-Xmx2g把最大堆内存设置为 2GB，-Xms512m让启动时直接预分配 512MB，避免频繁扩容。如果你机器内存充裕，也可以直接-Xmx4g。另一个重要系统属性是文件编码：
java -Dfile.encoding=UTF-8 -jar jd-gui-1.4.0.jar这个属性主要影响字符串在 GUI 内的渲染和保存时的编码行为，在中文环境下建议固定加上。把这些参数固化在一个启动脚本里，是最省事的做法。我在/opt/tools下放了这样一个脚本：
#!/bin/bash JAR_DIR="/opt/tools/jd-gui-1.4.0" JAVA_CMD="/usr/libexec/java_home -v 11 --exec java" exec $JAVA_CMD -Xms512m -Xmx2g -Dfile.encoding=UTF-8 \ -jar "$JAR_DIR/jd-gui-1.4.0.jar" "$@"保存为jdgui.sh，执行chmod +x jdgui.sh之后，后续都用./jdgui.sh /path/to/a.jar启动。脚本里的"$@"会把你在命令行传入的所有路径原样传给 JAR，这样路径里有空格也不怕。之所以不直接写java而是用java_home -v 11 --exec java，是为了避开本机默认 JDK 版本带来的各种兼容问题，这一步就是我把“玄学闪退”变成稳定复现的后悔药。
5. 避坑指南：JD-GUI 1.4 在 Mac 上的常见问题与排查
5.1 启动闪退：Gatekeeper、Java 版本与架构
现象是双击.app图标后 Dock 栏图标出现一下立刻消失，没有任何提示。从终端执行java -jar启动时则可能直接报UnsupportedClassVersionError或者AWTError: Can't connect to the display（后者多出现在远程环境）。
原因分三类：第一是 Gatekeeper 拦截，旧版应用没有签名，系统 默认拒绝；第二是 JDK 版本与 JD-GUI 1.4 编译目标不匹配，比如 JDK 17 起模块化限制导致运行时InaccessibleObjectException；第三是在 Apple Silicon 机器上混用了 x86 版 Java，导致启动时架构切换问题。
解决顺序是：先用右键打开.app确认 Gatekeeper 问题。如果不生效，把.app丢掉，改用 JAR 方式启动，日志里会给出具体异常。看到UnsupportedClassVersionError就换 JDK 8 或 11；看到InaccessibleObjectException优先换 JDK 11；看到Wrong architecture则检查java -version里有没有aarch64，没有就装 ARM 版 JDK 并使用第 2 章提到的java_home -V路径。一条条排下来，基本上 90% 的闪退都能定位。
5.2 中文乱码：字体还是编码？
现象是源码区的中文注释全部显示成方块或问号，有些字符串常量里的中文也乱码。直接用 JD-GUI 保存源码之后，用 IDE 打开乱码依旧。
原因有两个层次：第一是 JD-GUI 默认字体里没有中文字形，汉字渲染成方块；第二是启动参数缺少-Dfile.encoding=UTF-8，导致输出文件或界面读取时按系统默认编码处理。
解决方法是先退出 JD-GUI，加启动参数-Dfile.encoding=UTF-8再启动。如果乱码还在，就在 JD-GUI 的偏好设置里调整字体，找一个包含中文字形的字体，比如 macOS 上的PingFang SC或Songti SC。设置之后重新打开 JAR，乱码问题基本消失。注意，如果你的 JAR 其实是 GBK 编码的.java编译出来的，class 文件字符串常量仍是 UTF-8，现代 JVM 在 class 里保存的字符串一律是修改过的 UTF-8，所以 JD-GUI 层面乱码更多是字体问题，不要被网上的“编码转换”误导，盲目去改源文件。
5.3 大 JAR 卡死：堆内存与索引时间
现象是打开一个包含几千个类的 JAR，界面长时间无响应，鼠标变成彩虹转圈，CPU 持续 100%。如果你还同时开了多个 JD-GUI 窗口，内存占用会直接飙到几 GB。
原因是 JD-GUI 在打开文件时会对整个 JAR 做全量解析和索引，把所有 class 的元数据读进内存。默认堆内存不够时，GC 频繁，界面卡死是天然结果。还有的人在 4.2 节的批量启动脚本里一次性开了几十个窗口，那是在自找麻烦。
解决方法是先按第 4 章加-Xmx2g甚至-Xmx4g；其次，不要一次打开多个大 JAR。如果仍然卡，就在打开前先把你真正需要的类单独抽出来打成小 JAR。怎么抽？直接unzip目标 JAR 的某个包路径：
mkdir small && cd small unzip /path/to/large.jar "com/example/xxx/*" jar cf small.jar .把small.jar拖进 JD-GUI，索引速度会快一个数量级。这里的原理是缩小 JD-GUI 的解析范围，避开它对全部类做统一次序解析的耗时。抽取时注意保留完整包路径，否则类之间的引用关系会断裂。
5.4 导出的源码编译不通过：反编译不是原样
现象是从Save All Sources导出的工程目录，丢进 IDE 或直接用javac编译，报出一堆找不到符号、泛型不匹配、构造方法缺失的错误。
原因是反编译工具输出的是语义等价的源码，不是编译器可以完美重塑的源码。字节码本身不包含注释、局部变量名（除非有调试信息）、泛型擦除后的精确边界，lambda 更是被编译成了隐藏类，这些都无法从 class 里完整恢复。还有一个常见陷阱：JD-GUI 对枚举和内部类的处理会生成$VALUES、access$000这类合成方法，手工补代码时容易误删。
解决方法是先确认你的目标到底是阅读还是二次开发。如果是阅读，直接在这个乱代码上看逻辑，别管能不能编译；如果是二次开发，把反编译源码当作“带注释的伪代码”，逐个类对照javap -p -c输出，把缺失的方法签名和泛型边界补上。我见过有人拿反编译源码直接上线，出了一个隐蔽的ClassCastException，就是因为泛型擦除后他误写了一个List<Object>。从那以后我导出的源码一定先跑编译，再谈修改。
6. 进阶验证技巧：把反编译结果和字节码对照看
6.1 用 javap 对照方法签名
JD-GUI 的源码视图适合快速阅读，但最终判断一个方法到底做了什么，还是要回到底层字节码。JDK 自带了一个javap命令，它是验证反编译结果最可靠的工具。对某个 class 做反汇编时，我喜欢用：
javap -p -c -s -constants /path/to/module/Name.class-p显示私有成员；-c输出字节码；-s输出方法签名；-constants在字节码中直接显示常量池里的字符串和数字。使用场景很典型：JD-GUI 里看到一个方法调用helper.doSomething()，但你怀疑它其实调用了静态方法，此时javap的字节码里会清清楚楚看到invokestatic还是invokevirtual。对照着看，能快速识别 JD-GUI 误把抽象方法还原成普通方法等情况。
具体操作是把导出的.java文件找出来，定位到类名，再在原始 class 所在目录执行上面的命令，把输出重定向到文本：
javap -p -c -s -constants ./com/example/Name.class > Name_bytecode.txt然后用编辑器开两个文件，左边Name_bytecode.txt，右边 JD-GUI 源码，按方法名逐一对。这个方法看起来笨，实际排查复杂逻辑时非常稳，比反复猜测靠谱得多。
6.2 用脚本检查导出文件的包结构
批量导出之后，我还会跑两个小检查，确保没有漏导出或生成的目录结构异常：
cd /path/to/exported_src find . -name "*.java" | wc -l find . -type d -empty -delete第一条统计导出文件总数，和原始 JAR 里的 class 数量对一下。用unzip -l original.jar | grep '.class' | wc -l可以算出 class 数，两者大致一致就说明导出没有漏大块。第二条删除导出过程中生成的所有空目录，这通常是因为原 JAR 里目录本身只有资源文件，而资源文件没有被正确归类到resources，空目录会让 IDE 误认为包结构损坏。执行完成后再次find . -name "*.java"确认关键类存在，然后才把目录加入工程。
把 JD-GUI 1.4 当成日常审阅工具后，我的习惯已经固定为四步：先哈希验包，再用指定 JDK 启动，打开 JAR 后先看 Bytecode 视图再决定是否导出，导出后用javap对照签名。这套流程虽然比直接双击多花几分钟，但换来的是不再被闪退和乱码折腾。从那以后我每次拿到旧 JAR 都要强制走一遍，尤其在看第三方依赖时，一定先对照字节码再改代码，避免把反编译的伪代码当原始实现。希望帮到你。
本文还有配套的精品资源，点击获取
