VerifyError 是类加载时字节码校验失败，发生在 ClassLoader.defineClass() 阶段，非运行时异常；因字节码违反 JVM 规范（如类型不匹配、栈不平衡），常见于混淆、热替换、跨版本编译或手动修改字节码。
VerifyError 是类加载时字节码校验失败，不是运行时异常
Java 的 VerifyError 在类被加载进 JVM 时抛出，不是执行到某行代码才触发。它意味着 JVM 拒绝加载这个类——因为字节码不符合 JVM 规范，比如方法返回类型不匹配、栈帧不平衡、非法跳转等。常见于混淆、热替换、跨版本编译或手动修改字节码后。
关键点：它发生在 ClassLoader.defineClass() 阶段，不是 new X() 或调用某个方法时。所以堆栈里往往看不到你写的业务代码，只有 ClassLoader 相关调用链。
- 不是
ClassNotFoundException或NoClassDefFoundError：后者是找不着类；VerifyError是“找着了，但不敢用” - 不是所有 JVM 都默认开启校验：Java 8 开始，
-Xverify:none可跳过（仅限调试），但生产环境禁用 - 模块化（Java 9+）下，如果模块声明的
exports和实际字节码访问指令冲突，也可能在校验阶段失败
javap -c 是定位 VerifyError 最快的手段
拿到报错类的全限定名后，立刻用 javap -c 反编译其字节码，重点看报错方法的指令序列。JVM 报错信息通常带行号或方法名，但没说哪条指令越界——javap 能帮你对齐。
例如报错：java.lang.VerifyError: Bad type on operand stack，大概率是某个 invokevirtual 前压入的栈顶元素类型和目标方法签名不兼容，比如把 Integer 当 int 传给需要基本类型的函数。
立即学习“Java免费学习笔记（深入）”；
- 用
javap -c -verbose ClassName查看常量池、局部变量表、栈帧最大深度（max stack） - 对比编译源码和实际加载的 class：是否用了不同 JDK 版本编译？比如 Java 17 编译的 class 被 Java 8 加载（major version 不匹配会先报
UnsupportedClassVersionError，但某些中间版本混用可能撑到校验阶段才崩） - 注意 Lombok、MapStruct 等注解处理器生成的字节码：它们可能在编译期注入非法指令，尤其升级插件后未 clean 重建
ASM / Javassist 修改字节码后 VerifyError 高发
手动操作字节码（如 AOP、监控探针、测试 mock）是最容易触发 VerifyError 的场景。哪怕只改了一条 iconst_0，也可能破坏栈平衡或类型流。
典型错误：在方法末尾插入日志逻辑，但忘了调整 max stack 和 max locals；或在 try-block 内插入 return，却没同步更新 exception table。
- 用
ASMifier工具反推目标方法原始字节码结构，再比对你的修改是否维持了控制流完整性 - Javassist 的
CtMethod.insertBefore()默认不校验插入代码的类型安全性，建议后续加ctMethod.getMethodInfo().setCodeAttribute(null)强制重算属性（慎用，影响性能） - 测试时务必在目标 JDK 版本上跑，不要只在编译环境验证：不同版本 JVM 对“宽松校验”的容忍度不同
VerifyError 在 Android 上更隐蔽，需区分 Dalvik 和 ART
Android 5.0（Lollipop）起默认用 ART 运行时，它在安装时就做 AOT 预校验（dex2oat），所以 VerifyError 通常出现在应用首次启动前，表现为安装失败或闪退无日志。而 Dalvik 是 JIT 校验，更容易在运行中暴露。
ART 下常见诱因：使用了 Java 8+ 的 lambda 表达式但没配置 compileOptions.sourceCompatibility，导致 desugar 后的辅助类字节码不合规；或第三方 SDK 提供的 dex 包含针对高版本 JVM 优化的指令（如 invokedynamic），ART 低版本不支持。
- 查
adb logcat | grep -i "verify"，ART 通常会打印具体校验失败原因，比如Rejecting class ... because its verifier rejected it - 用
dexdump -d classes.dex | grep -A 20 "YourClassName"粗略看字节码结构，确认是否存在非法 opcode - 启用
android.enableD8.desugaring = true并确保 AGP 版本 ≥ 4.2，避免旧版 desugar 引入校验漏洞
字节码校验本身不报错，但一旦报错，说明已有不可逆的结构性问题——修复必须回到编译或字节码生成环节，运行时无解。最麻烦的是那种只在特定 CPU 架构（如 arm64-v8a）上触发的校验失败，得连真机 + 对应 ABI 的构建产物一起查。
