因突发Bug技术总监无法解决，竟直接要求项目中禁用lombok！

摘要：按理说，这种问题稍微熟悉 Java 项目构建的同学应该能很快定位解决吧？升级 JDK 版本、调整依赖、配置 annotationProcessor，没啥特别难的。

因一个Bug，Lombok被全盘禁用

这件事简直让我联想到小时候在学校，有个熊孩子不小心把玻璃打碎了，结果老师气得把全班的篮球都没收了。

话说有一天，某公司技术总监在打包项目的时候，突然遇到了一个莫名其妙的 Bug。从截图上看，报错信息挺直白：

java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor...

嗯？这不就是经典的 Lombok “锅”吗？看这错误栈，显然是某种依赖版本冲突，导致编译时 Lombok 的注解处理器加载失败。

按理说，这种问题稍微熟悉 Java 项目构建的同学应该能很快定位解决吧？升级 JDK 版本、调整依赖、配置 annotationProcessor，没啥特别难的。

但这位技术总监的解决方法更简单粗暴——直接禁用 Lombok！

团队所有人被强制要求在项目中删掉 Lombok 的依赖，回归到手写 Getter、Setter 的“原始时代”。这波操作一出，团队的小伙伴顿时集体炸锅，纷纷表示：“这也太离谱了吧！”

Lombok 是 Java 开发圈子里非常流行的工具，主要功能是通过注解的方式简化冗余代码，比如自动生成 Getter、Setter、ToString、Equals、HashCode 等方法。用过它的同学应该都知道，这玩意最大的优点就是让代码变得简洁优雅。

举个例子，使用 Lombok 写一个简单的 Java 类：

@Data // Lombok 注解，一键生成 Getter、Setter、toString 等方法public class User { private String name; private int age;}

只需要短短几行代码，就搞定了所有属性方法。而不用 Lombok 的话，你得像下面这样手写：

public class User { private String name; private int age; public String getName { return name; } public void setName(String name) { this.name = name; } public int getAge { return age; } public void setAge(int age) { this.age = age; } @Override public String toString { return "User{name='" + name + "', age=" + age + "}"; }}

兄弟们，手写 Getter 和 Setter 的时代，我们不是已经告别了吗？！

然而，Lombok 也不是没有缺点。比如：

编译器依赖问题：它本质上是通过注解处理器来操作字节码，如果编译器或者 JDK 版本不兼容，就可能出现运行时错误。可读性问题：对于刚接触项目的开发者来说，Lombok 的魔法操作可能显得不够直观，导致代码的“可读性”下降。

不过这些问题，靠一点小小的调试和配置就能解决啊，完全不至于“因噎废食”到禁用的地步。

来看总监的做法。遇到 Bug，直接禁用工具，听起来有点像“车胎漏气了，直接把车报废了”的感觉。但换个角度看，也能理解一些老程序员的心理。很多人可能觉得：

Lombok 是“语法糖”，虽然好用，但依赖这种工具，未来出了问题不好排查。手写代码才是最稳妥的，什么 Getter、Setter，不写出来都不安心。

这种想法虽然“保守”，但不能否认，有些大厂开发的确对 Lombok 有些抵触。比如：

Lombok 的注解功能是通过字节码增强实现的，在某些复杂场景下可能会导致依赖冲突或者编译问题。一些追求高稳定性的大型项目，为了避免工具带来的潜在风险，会选择放弃这种“语法糖”。

不过话又说回来，问题的本质是：技术总监连 Bug 的根因都没搞清楚，就直接选择禁用工具，属实有点懒得分析了。

要解决这个问题，我们需要搞清楚几个点：

JDK 版本兼容性：使用的是 javac 17.0.9。在 Java 16+ 中，某些模块化特性会对 Lombok 的注解处理器产生影响。依赖冲突：Lombok 的版本和项目中其他依赖（比如 Spring Boot）版本是否兼容？