这是注解处理器生成非法java结构引发的编译器内部崩溃，表现为无行号的“internal compiler error”，需通过禁用处理器、检查生成方法重复、升级库或校验签名来修复。
这类问题不是普通的方法重名编译错误，而是注解处理器（Annotation Processor）在处理自定义注解时，因内部生成的辅助类或桥接方法出现同名冲突，导致 javac 在编译期 AST 构建或字节码生成阶段崩溃，表现为“Compilation failed: internal java compiler error”或直接卡死、无响应。它不报具体行号，也不提示“duplicate method”，而是让整个编译链中断——本质是注解处理器输出了非法 Java 结构，触发了编译器底层断言失败或 ClassWriter 异常。
确认是否为注解处理器引发的内部崩溃
先排除普通语法错误，聚焦三类强信号：
- 错误日志含 “internal compiler error”，但无明确源码位置，且堆栈末尾频繁出现
com.sun.tools.javac或javax.annotation.processing相关类 - 仅在启用某特定注解（如
@Data、@Builder、自研注解）时复现；禁用后编译立刻通过 - 同一段代码，在 JDK 17 下报错，换 JDK 21 就正常；或在 Maven 命令行编译失败，但 IDE 内置编译器（ECJ）却能过
快速隔离与临时绕过
不改业务代码的前提下，优先验证和缓解：
- 在
pom.xml中临时注释掉对应注解处理器依赖（如 Lombok 的lombokscope=compile），再 clean + compile - 若使用 IntelliJ，进 Settings → Build → Compiler → Annotation Processors，关闭“Enable annotation processing”并重启 IDE
- 对单个类加
@SuppressWarnings("all")并移除所有相关注解，观察是否恢复编译
定位冲突根源：检查生成逻辑中的方法签名
注解处理器常会为类自动注入 getter/setter/toString 等方法。当多个注解（如 Lombok @Data + 自研 @Trace）同时作用于一个类，且都试图生成同名方法（如 toString() 或 hashCode()），而处理器未做去重或覆盖协商，就会输出重复方法体，违反 JVM 字节码规范。
验证方式：
- 开启注解处理器调试输出：
-Dorg.slf4j.simpleLogger.defaultLogLevel=debug（Lombok）或添加-XprintProcessorInfo（javac） - 用
javap -c YourClass.class查看已编译类，搜索重复方法名；若发现两个public java.lang.String toString()方法体，即确认冲突 - 检查自研注解处理器中
RoundEnvironment遍历逻辑，确认是否对已有方法做了ElementFilter.methodsIn(typeElement.getEnclosedElements())判重
根本修复策略
从工具链层面收敛问题：
- 统一注解方案：项目中避免混用 Lombok + MapStruct + 自研注解生成器；优先选用一套成熟方案，并禁用其余的 processor
- 升级注解库版本：Lombok 1.18.30+ 已修复多注解共存下
toString()重复生成问题；MapStruct 1.5.5+ 加强了 default 方法覆盖检测 - 自研 processor 必须实现方法存在性校验：在
JavaFileObject.openOutputStream()写入前，扫描目标类已有的方法签名，跳过已存在且签名一致的生成项 - 对关键类显式声明被覆盖方法：例如手动写一个空的
public String toString() { return super.toString(); }，可阻断注解自动生成，避免冲突
