VerifyError 表示字节码结构合法但类型推导失败（如栈类型不匹配），ClassFormatError 表示字节码二进制损坏（如魔数错误、常量池异常）；二者均发生在类加载验证阶段，需据异常提示区分根因并针对性排查工具链兼容性。
OpenJDK 升级后字节码处理库（如 ASM、CGLIB、Byte Buddy）报 VerifyError 或 ClassFormatError，基本可判定是工具链与新 JVM 的验证逻辑不兼容——不是你的代码写错了，而是字节码生成/修改环节没跟上 JDK 的校验收紧节奏。
怎么看是 VerifyError 还是 ClassFormatError？
二者都发生在类加载的验证阶段，但根因完全不同，必须先分清：
-
VerifyError：堆栈第一行含Bad type on operand stack、Expecting to find object/array on stack等提示 → 字节码结构合法，但类型推导失败；典型于 CGLIB/ASM 动态生成代理类时未正确计算栈帧 -
ClassFormatError：堆栈含Incompatible magic value、bad constant pool tag、Truncated class file→ 字节码二进制已损坏；常见于混淆器（ProGuard/R8）或自定义 ClassWriter 写入异常、网络传输截断、临时目录空间满导致写半截文件 - 类名含
$$EnhancerByCGLIB$$、$$ByteBuddy$$、$$FastClassBySpringCGLIB$$→ 基本锁定为动态代理工具问题，优先查 CGLIB/ASM 版本与 JVM 兼容性
为什么 JDK 17+ 后 VerifyError 突然变多？
JDK 9 起默认启用更严格的字节码验证器，JDK 17 彻底移除对旧式栈帧（COMPUTE_MAXS）的容忍。关键变化：
- CGLIB 3.2.x 默认不启用
COMPUTE_FRAMES，在 JDK 17+ 下生成的类缺少StackMapTable属性，验证器直接拒载 - ASM 若手动调用
visitMethodInsn或修改局部变量表，却用COMPUTE_MAXS而非COMPUTE_FRAMES，会导致栈帧推导错误 - Byte Buddy 1.12.0+ 才完全适配 JDK 21 的模块化限制（如
--add-opens java.base/java.lang=ALL-UNNAMED不再自动生效）
怎么快速定位出问题的 class 文件？
不能只信日志里的类名，要捞出真实字节码验证：
- 从报错信息提取完整类名（如
com.example.Service$$EnhancerBySpringCGLIB$$a1b2c3d4），用ClassLoader.getSystemResourceAsStream("com/example/Service$$EnhancerBySpringCGLIB$$a1b2c3d4.class")写到磁盘，或检查临时目录（如/tmp/cglib-、/tmp/byte-buddy-） - 执行
javap -v ClassName.class | grep "major version"确认编译目标版本（61=JDK 17，65=JDK 21）；若高于当前 JVM 版本，说明工具内部用了高版本 ASM 编译器 - 执行
javap -c ClassName.class找到报错方法，重点核对：压栈指令（aload_0）、参数类型签名、invokevirtual目标方法是否匹配，以及StackMapTable是否存在
常见字节码库的修复要点
不同工具风险点差异大，按需排查：
- CGLIB：强制升级到
cglib-nodep:3.3.0+，并用mvn dependency:tree确认无旧版cglib:3.2.2被 transitive 依赖带入；Spring Boot 3.x 已弃用 CGLIB，改用 JDK 代理或 Byte Buddy - ASM：所有
ClassWriter实例必须传入ClassWriter.COMPUTE_FRAMES（非COMPUTE_MAXS）；若使用MethodVisitor修改字节码，确保visitMaxs被跳过（由COMPUTE_FRAMES自动填充） - Byte Buddy：升级至
1.12.20+，并在 JVM 启动参数中显式添加--add-opens java.base/java.lang=ALL-UNNAMED（JDK 17+ 必须） - ProGuard/R8：禁用
-mergeinterfacesaggressively，加-printconfiguration核对实际生效规则；开启-allowaccessmodification时需同步加-repackageclasses ''避免桥接方法签名破坏
最易被忽略的是：字节码工具的 transitive 依赖版本冲突。比如 Maven 中声明了新版 ASM，但某个老 SDK（如某银行中间件客户端）自带旧版 ASM 并打包进 fat jar，运行时优先加载了旧版，导致生成逻辑降级失效——这种问题必须用 java -verbose:class 或 Arthas 的 sc -d * 查实际加载的类路径。
