Hibernate字节码增强插件导致Spring Boot项目启动抛出MappingException异常

我完全懂你现在的困扰——本来想靠Hibernate字节码增强解决烦人的N+1查询问题，结果项目直接启动崩溃，排查了Java版本没问题，实体类看起来也没毛病，确实让人摸不着头脑。咱们来一步步拆解这个问题：

从你提供的报错栈来看，核心问题是java.lang.VerifyError: Operand stack overflow，而且明确指向了InternalTransaction实体生成的增强类里的set_amount方法操作数栈溢出。结合你用的是Kotlin+单表继承+Hibernate增强的组合，我给你几个针对性的解决方案：

1. 先调整Hibernate增强的配置项 #

你当前开启了enableExtendedEnhancement这个扩展增强选项，它在Kotlin实体+单表继承的场景下，很容易和Kotlin的类结构（比如open类、属性的默认get/set方法）产生冲突，导致生成的字节码不符合JVM规范，进而引发栈溢出。

先把这个选项关掉试试，修改build.gradle.kts里的Hibernate配置：

hibernate {
    enhancement {
        enableDirtyTracking
        enableLazyInitialization
        enableAssociationManagement
        // 注释掉扩展增强选项
        // enableExtendedEnhancement
    }
}

之后执行./gradlew clean build，清理项目后重新构建启动，看看问题是否解决。其实基础的脏跟踪、懒加载、关联管理已经能覆盖大部分N+1查询的优化场景，扩展增强很多时候不是必需的。

2. 检查Kotlin实体类的属性声明 #

你的InternalTransaction是open类，属性也都是open的，这虽然符合Spring Data JPA的继承要求，但Hibernate的字节码增强在处理Kotlin的属性访问器时可能存在兼容性问题。你可以尝试给amount属性加上@JvmField注解（注意：这个注解会让属性直接暴露为字段，可能影响Hibernate的代理逻辑，建议先测试）：

@JvmField
open var amount: Double,

另外确认Kotlin编译参数没有冲突，你已经设置了jvmTarget=17，这个是对的，没必要额外添加其他可能影响字节码的参数。

3. 彻底清理构建缓存 #

有时候旧的构建缓存里残留的字节码会和新生成的增强字节码冲突，导致奇怪的错误。执行下面的命令彻底清理缓存后重新构建：

./gradlew clean build --no-build-cache

4. 逐步排查增强选项 #

如果上面的方法都不行，你可以尝试逐步开启增强选项，排查到底是哪个选项触发的问题：

• 先只开启enableDirtyTracking，启动项目；
• 没问题的话，再加enableLazyInitialization，启动；
• 以此类推，直到找到触发栈溢出的选项，然后针对性地调整。

如果所有方法都无效，建议暂时禁用Hibernate字节码增强，先确保项目能正常启动，再慢慢排查是否是Hibernate版本和Kotlin的兼容性bug（虽然你用的是Spring Boot捆绑的版本，但也不排除存在特定场景的bug）。

备注：内容来源于stack exchange，提问作者Amirhossein