最稳用cfr反编译插件：兼容java 17新特性，需禁用idea自带解码器；遇“decompiled code not available”需检查module-info、混淆或jdk类配置；var丢失因编译未加-g:vars；空方法体是cfr对不支持字节码的兜底处理。
IntelliJ IDEA 里装哪个反编译插件最稳
用 CFR，别选 Jad 或默认的 Procyon（新版 IDEA 自带那个）。Jad 已停更多年，遇到 Java 8+ 的 lambda、try-with-resources、模块化语法直接崩；Procyon 对泛型擦除后重载方法识别不准，常把 list.get(0) 反成 list.get((Integer)0) 这种错类型调用。CFR 更新勤、兼容性好，Java 17 的 sealed class 和 record 都能稳住。
安装路径：Settings → Plugins → 搜 CFR Decompiler → 点 Install。装完不用重启，但得关掉自带的 Java Bytecode Decompiler（在同一个插件页里禁用它），否则俩插件抢着干活，结果随机出错。
点开 .class 文件却显示“Decompiled code is not available”
这是 IDEA 没把该类识别为可反编译目标，常见于三种情况：
- 项目用了
module-info.class—— CFR 默认不处理模块描述符，删掉或手动跳过它 - 类被混淆（比如
a.b.c.d这种包名 + 单字母类名）—— CFR 能反，但变量名全丢，得配合mapping.txt手动对齐 - 类来自
rt.jar或 JDK 内置模块（如java.base）—— IDEA 默认走源码挂载逻辑，得进 Settings → Languages & Frameworks → Java → Class Decompile 设置里，勾上Decompile library classes
反出来的代码里 var 全没了，全是 Object 或 Object[]
这不是插件问题，是编译时没保留局部变量表（-g:vars）。CFR 依赖 class 文件里的 LocalVariableTable 属性还原类型，而很多构建工具（尤其 Maven 的 maven-compiler-plugin 低版本）默认只打 -g:lines,source。
立即学习“Java免费学习笔记（深入）”；
检查你的 pom.xml：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.11.0</version>
<configuration>
<debug>true</debug>
<debuglevel>source,lines,vars</debuglevel>
</configuration>
</plugin>
改完重编译一次，再点开 .class 就能看到真实类型了。
为什么有时候反编译出来的方法体是空的，只有一行 throw new UnsupportedOperationException();
这是 CFR 遇到它解析不了的字节码模式（比如某些 Kotlin 内联函数生成的异常块、GraalVM native image 的 stub 类），不是你配置错了。它会 fallback 到这个兜底逻辑，避免抛异常卡死 IDE。
此时可以：
- 右键该类 →
Open Library Source（如果有源码 jar 挂载） - 用命令行手动跑
cfr.sh YourClass.class --outputdir ./out，看终端输出有没有 warning，比如Unsupported opcode: INVOKEDYNAMIC - 换用
javap -c YourClass.class看原始字节码指令，确认是不是用了 JVM 15+ 的新特性（CFR 1.0.16 支持到 19，但某些 preview 特性仍不支持）
真遇到这种 case，别硬刚反编译，直接查对应开源项目的 release tag 或 git commit，比猜字节码靠谱。
最麻烦的是混合了 Kotlin + Java + GraalVM 的项目，反编译只是辅助，关键逻辑还得看 build 产物里的 actual jar 包和对应的 build log。
