VerifyError 是 JVM 拒绝加载类时抛出的致命错误
它不是普通异常，而是 java.lang.Error 的子类，意味着程序已处于不可恢复状态。JVM 在类加载的“验证”阶段发现字节码存在逻辑矛盾——比如操作数栈类型错配、非法类型转换、局部变量表越界等，直接中断加载。一旦出现，该类无法初始化，后续所有依赖它的代码都会失败（如 Spring Bean 创建失败、AOP 代理崩溃、甚至应用启动卡死）。
Bad type on operand stack 这类错误怎么快速定位
这是 VerifyError 中最常见也最具体的提示，说明方法字节码在执行前就被校验器判为“类型不安全”。典型场景是：动态代理（CGLIB/ASM）、AOP 织入、或使用了旧版字节码工具生成的 class，在新 JVM 上运行时被更严格的验证规则拦截。
- 先用
javap -v ProblemClass.class | grep "major version"确认类文件编译版本，对照 JDK 主版本号（如 52 → JDK 8，61 → JDK 17），确保不高于运行时 JVM 版本 - 再用
javap -c ProblemClass.class查看报错方法的字节码，重点检查astore/aload、invokevirtual前后的栈顶类型是否与方法签名一致 - 如果用了 Spring AOP 或 MyBatis Plus，检查
spring-aop和aspectjweaver是否版本冲突（例如 spring-aop 5.3.x + aspectjweaver 1.9.7 是已知高危组合）
为什么加 -noverify 或 -Xverify:none 不是解法
这两个 JVM 参数确实能绕过校验让程序“跑起来”，但代价是放弃 JVM 最基础的安全屏障——类型安全。它不会修复问题，只是掩盖字节码缺陷，可能导致后续运行时出现诡异的 ClassCastException、静默数据错乱，甚至 JVM 崩溃。尤其在生产环境，等于主动拆掉刹车去跑山路。
-
-Xverify:none自 JDK 13 起已被废弃，JDK 17+ 直接忽略；JDK 8–12 仍支持，但日志会明确警告 “Verification disabled” - Android ART 虚拟机完全不支持该参数，Dalvik 早已淘汰，所以移动端无效
- 真正有效的临时规避只有一种：
-XX:+UnlockExperimentalVMOptions -XX:+EnableUnsafeVerification（仅限 OpenJDK 11+ 实验性选项，且需确认风险）
Spring Boot 启动报 Unable to load cache item 时的实操路径
这个错误常出现在 Spring Boot 2.6+ + JDK 17 组合中，本质是 CGLIB 生成的代理类被新 JVM 的强校验拒绝。不是你的代码写错了，而是框架字节码和 JVM 规则之间出现了代际断层。
立即学习“Java免费学习笔记（深入）”；
- 优先降级 CGLIB：在
pom.xml中强制指定cglib-nodep:3.3.0（兼容 JDK 17 验证规则） - 升级 Spring Boot 至 3.1+ 并切换到 JDK 17+ 的正式支持分支（避免使用 3.0.x 这类过渡版本）
- 若用 Lombok，确认
lombok.version≥ 1.18.30，旧版生成的builder()字节码易触发栈类型错配 - 清理
target/classes和~/.m2/repository中对应模块的缓存，避免混合了不同编译器生成的 class 文件
