Lombok 1.18.48 遇到 javac 27 和通配导入时报 AssertionError

项目换到 JDK 27 后，Java 编译没有给出普通类型错误，而是抛出 java.lang.AssertionError。栈中出现 Attr.visitTree、JCTree$Visitor.visitVarType 或 JCVarType.accept，出错类又同时有 import lombok.*; 和局部变量 var，可以先核对 Lombok 1.18.48 的这一组合。

即使那个源文件没有使用 Lombok 注解，一条尚未清理的通配导入也可能参与触发。故障既能经 Maven 出现，也能在直接调用 javac 时出现，因此不能只把它当成 Maven 插件报错。

把通配导入收窄到实际注解

若该文件没有使用任何 Lombok 类型，删除无用的 import lombok.*;。确实需要注解的文件，则改成实际用到的精确导入。例如：

import lombok.Getter;

class Entity {
    @Getter
    private String name;

    static Entity create() {
        var entity = new Entity();
        return entity;
    }
}

这里保留了原生 var，也保留 Getter 的生成行为。其他文件使用 Setter、Builder 等类型时，应分别添加对应导入，不能为了让这一处编译通过便去掉全部注解处理器，随后把缺失的生成方法当成另一轮业务错误。

这条调整针对 javac 27、Lombok 1.18.48、通配导入与 var 同时存在的路径。若精确导入后仍崩溃，应保留完整的编译器栈和最小源文件，继续核对实际使用的处理器版本与其他编译扩展；不能把所有 AssertionError 都归为同一原因。

--release 25 仍然可以由 javac 27 执行

--release 约束源语言与目标平台 API，不负责选择编译器进程。Maven 仍由 JDK 27 的 javac 执行时，添加 --release 25 不等于换回 JDK 25，这个组合仍可能失败。

如果项目原本就允许使用 JDK 25 工具链，选择实际的 JDK 25 编译器是另一项可评估的调整；需要同时核对 Maven Toolchains、IDE 和 CI 的编译器选择。依赖或源代码要求 JDK 27 时，不能仅为避错而改变平台目标。优先收窄导入，往往更容易保留原有构建约定。

不把开发版条目当成正式修复

截至 2026 年 10 月 24 日，Maven Central 的正式 Lombok 版本仍为 1.18.48。它增加了 JDK 27 支持，但这不意味着该版本已解决这里的通配导入与 var 崩溃。开发版 1.18.49 的变更中已有对应修正，不能因此把一个尚未正式发布的版本写进常规依赖升级方案。

将来采用包含该修正的正式版本时，仍需核对实际 annotation processor path，而不只看应用运行依赖。用同一个小类检查编译产物及生成的 getter，再回查项目其他注解生成代码。IDE 能通过、CI 仍崩溃时，先对照两边真正执行的 javac 与处理器，不必继续堆叠 release 参数。