你好，我是猿java。

作为 Java开发人员，我们都知道 Java中有大量类似于 getter、setter、toString样板代码，为了解决这个问题，Lombok诞生了，那么，Lombok是银弹吗？生产环境建议使用 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注解的使用示例：

java 复制代码

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也可以快速生成；
基于上述 4个考虑因素的任何一个，引入 Lombok都不是一个很好的决定；
网上还看到 Lombok很多花哨的使用方式，这样潜在的风险越大；

最后，项目中是否使用 Lombok，取决于个人喜好以及团队和项目的选择，上述的考虑因素或许可以给你的决策多一个参考。

学习交流

文章总结不易，看到这里的小伙伴，感谢帮忙点赞，在读，或者转发给更多的好友，我们将为你呈现更多的干货，欢迎关注公众号：猿java

Lombok是如何工作的？生产环境使用它需要考虑哪些因素？