Lombok与Micronaut冲突排查：从Id无法访问到DDL约束失效

以下是可能导致两个项目Lombok表现差异的核心原因：

• Lombok依赖配置不完整
  第二个项目大概率缺失了Lombok注解处理器的配置。比如在Gradle中，仅引入compileOnly 'org.projectlombok:lombok'是不够的，必须同时添加annotationProcessor 'org.projectlombok:lombok'；Maven项目则需要确保lombok-maven-plugin在编译阶段正确配置。第一个项目的依赖配置完整，编译时Lombok能正常生成getter、Builder等代码，而第二个项目因为注解处理器缺失，导致编译时无法识别Lombok注解，出现属性访问、Builder失效等问题。

• IDE与构建工具的编译逻辑不一致
  第二个项目的IDE（如IntelliJ）可能未开启Lombok注解支持，或者IDE使用自身编译流程而非委托给Gradle/Maven。这种情况下，IDE编译时不会触发Lombok的代码生成，而构建工具编译可能又存在缓存，导致代码逻辑混乱，出现依赖注入失败、DDL约束警告等问题。

• 版本兼容性冲突
  即便更换了Micronaut版本，第二个项目的Lombok版本可能与Micronaut的核心依赖存在兼容性问题。比如部分Lombok版本的@Builder实现会干扰Micronaut的JPA实体元数据解析，导致DDL约束无法正常应用；或者@RequiredArgsConstructor生成的构造函数无法被Micronaut的依赖注入容器识别。第一个项目使用的版本组合恰好规避了这类冲突。

• 注解使用不规范
  第二个项目的注解搭配可能存在问题：比如实体类仅使用@Getter而非@Data导致属性访问失败；@Builder与Micronaut的@Entity注解顺序错误，影响实体元数据解析；@RequiredArgsConstructor注入的依赖未添加@Singleton等Micronaut的Bean注解，导致容器无法识别并完成注入。第一个项目的注解使用更符合两者的搭配规范。

• 构建缓存残留
  第二个项目的构建缓存可能保留了未正确生成Lombok代码的旧编译产物，导致新的注解配置无法生效。执行./gradlew clean（Gradle）或mvn clean（Maven）清理缓存后重新编译，可能解决这类问题。

内容的提问来源于stack exchange，提问作者belmont