在 Java语言中，有大量类似于 getter、setter、toString 这样的模板代码，为了解决这个问题，一个流行的框架 Lombok诞生了。前几天看到腾讯的一道 2面题：Lombok是银弹？还是陷阱？生产环境建议使用 Lombok吗？今天我们一起来聊一聊。
Lombok是什么？
Lombok是一个三方开源的 Java库，通过注解可以自动将代码插入到编辑器和构建工具中，为 Java程序员省略了很多样板代码的编写，除了生成getter、setter方法，还可以生成 equals、hashCode和各种类构造函数等。在很多 Java程序员的眼中简直就是银弹。
Lombok如何使用？
Lombok的使用很简单，主要是通过注解来精简代码，常用的注解如下：
- @Getter：作用在类上，为实体类所有属性添加 getter方法；
- @Setter：作用在类上，为实体类所有属性添加 setter方法；
- @ToString：作用在类上，当调用toString()方法，可以输出实体类中所有属性的值。
- @Data：作用在类上，相当于同时使用了@ToString、@EqualsAndHashCode、@Getter、@Setter和@RequiredArgsConstrutor这些注解；
- @AllArgsConstructor：作用在类上，为实体类生成包含所有属性参数的构造方法；
- @NoArgsConstructor：作用在类上，为实体类生成无参构造方法；
- @RequiredArgsConstructor：作用在类上，配合@NonNull注解使用，生成指定参数的构造方法。比如在age属性前面加@NonNull注解，则User生成需要age参数的构造方法；
下面给出了一个 Lombok @Data注解的使用示例：
import lombok.Data;
@Data
public class User {
private String id;
private String name;
}
上述示例通过在类上使用 @Data注解后，我们就不需要再手动添加 getter、setter等模版代码，整个代码看起来简洁了很多。
Lombok如何工作？
从 Lombok如何使用的讲解中我们可以看到：Lombok主要是依赖注解来标识（标记）需要在该类中生成哪些代码。除此之外，还有一个重要的技术点是抽象语法树（AST）。
抽象语法树（AST，Abstract Syntax Tree）是一种用于表示程序源代码结构的树状数据结构。它抽象出代码的语法结构，忽略某些细节，以便于编译器或解释器进行分析和处理。
在 Java中，AST是一种在生成字节码之前创建的中间结构，如下图为 AST示例：
Lombok是注解和 AST的完美组合，Lombok通过识别注解，然后操纵 AST将不存在的样板代码插入到类中。
但是 Lombok并不是直接修改源代码文件，而是在编译过程中动态生成代码，为了实现这一点，Lombok需要拦截 Java编译器的调用，而这种拦截是通过插件来实现的，比如 IntelliJ, VSCode, Eclipse 或者在构建工具 Maven, Gradle, Make等。因此，如果选用的 IDE或依赖/构建管理器不支持 Lombok，代码将无法编译。
考虑因素
Lombok为 Java省略了很多样板代码的编写，但是，对于项目中使用 Lombok，我们还是应该多一些思考，这里主要总结为下面 4个考虑点：
编译时间
由于 Lombok在编译时完成样板代码的填充，因此，势必导致编译时间的增加，尤其是在大型代码库中，这种增加可能会有很大影响，尽管 Lombok随着版本的升级，性能也在提升，但使用 Lombok的时间仍然比不使用 Lombok的时间长。
友好性
Lombok大大减少了Java类中的样板代码，特别是在领域类（TOs、DTOs、实体）中，这些类通常有很多类级别的属性。
但是，使用 Lombok后，所有参与这个项目开发的技术人员都需要安装 Lombok插件，因此，对于不愿意使用 Lombok的开发人员来说不太友好。另外，如果团队中有刚工作的组员，如果一开始就在 Lombok这种环境下，那么对于他们的成长也是不友好的。
Java标准
在开发过程中，我们通常会使用 IDE或构建工具自动编译Java代码，所以 Lombok可以在这个阶段自动完成它的工作，但是，假如我们只是使用 javac来编译源代码，如果源代码中使用了 Lombok生成的get方法，这种情况下编译会出错提示get方法不存在。
兼容性
如果项目中涉及 JDK的版本升级，可能出现兼容性问题，因为每个版本可能会改变 AST的生成和解释方式。因此，如果使用了 Lombok，在升级 Java版本后，可能会导致项目无法编译。
尽管这个问题重新编译后可以解决，但是，如果使用了 Lombok，还是要注意上述提到的可能编译失败的问题。
开发和CR
Lombok 是在编译期为类生成样板代码，因此，开发人员在调试时看不到这些代码，可能会给调试带来一些困难，另外，Lombok 自动生成的代码是隐式的，可能会让代码行为不够透明，给代码审查和维护带来一些挑战。
总结
本文从面试题出发，讲解了 Lombok的工作原理以及其优点和需要考虑的因素：
优点
- 可以大大减少样板代码的手动编写；
考虑因素
- 编译时间
- 友好性
- Java标准
- 兼容性
- 开发和CR
个人建议
对于我个人而言，倾向于在项目不使用 Lombok，主要有以下 3个原因：
- Lombok只是减少样板代码，帮助程序员偷了懒，并没有给项目带来什么实质性的收益，而且这些样板代码 IDE也可以快速生成；
- 基于上述 5个考虑因素的任何一个，引入 Lombok都不是一个很好的决定；
- 网上看到了 Lombok很多花哨的使用方式，这样潜在的风险更大；
最后，项目中是否使用 Lombok，取决于个人喜好以及团队和项目的选择（大厂一般都会禁用 Lombok），但是，上述的考虑因素或许可以给你的决策多一个参考。