为什么不推荐使用Lombok？

首先见一下什么是Lombok？

什么是Lombok？

我们来看一下Lombok的官网介绍，地址：https://projectlombok.org

我们翻译来看一下：

Lombok项目是一个Java库，它会自动插入您的编辑器和构建工具中，从而使您的Java更加生动有趣。永远不用再写另一个getter或equals方法，带有一个注释的您的类有一个功能全面的生成器，自动化您的日志记录变量等等。

翻译可能不是很准确，但是简单来说，Lombok是一个可以帮助我们简化模板样式代码的Java类库，使用注解来简化你的模板代码，例如getter、setter，以及日志记录的log变量等等。

使用Lombok有什么好处？

1. 1.简化冗余的JavaBean代码；
2. 2.提高JavaBean中方法的执行效率；

以前我们写一个类需要这样：

public class User {
private String username;
private int age;
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
}

现在使用Lombok：

@Data
public class User {
private String username;
private int age;
}

这样代码就变得清爽了非常多，它是如何实现的呢？

首先是项目的源代码文件，在经过编译处理以后，lombok会使用自己的抽象语法树去进行注解的匹配，如果在项目中的某一个类中使用了lombok中的注解，那么注解编译器就会自动去匹配项目中的注解对应到在lombok语法树中的注解文件，并经过自动编译匹配来生成对应类中的getter或者setter方法，达到简化代码的目的。执行顺序就如上图的叠放顺序。

这么看来其实使用Lombok确实挺爽的，那为什么又不推荐使用呢？主要有以下几点原因：

1. JDK版本问题

如果想要将现有项目的JDK从Java 8升级到Java 11时，Lombok就不能正常工作了。于是不得不将所有的Lombok注解从项目源代码中清除，并使用IDE自带的功能生成getter/setter，equals，hashCode，toString以及构造器等方法，你也可以使用Delombok工具完成这一过程。但这终究会消耗你很多的时间。

2. 胁迫使用

当你的源代码中使用了Lombok，恰好你的代码又被其他的人所使用，那么依赖你代码的人，也必须安装Lombok插件(不管他们喜不喜欢)，同时还要花费时间去了解Lombok注解的使用情况，如果不那么做，代码将无法正常运行。

3. 可读性差

Lombok隐藏了JavaBean封装的细节，如果你使用@AllArgsConstructor注解，它将提供一个巨型构造器，让外界有机会在初始化对象时修改类中所有的属性。首先，这是极其不安全的，因为类中某系属性我们是不希望被修改的；另外，如果某个类中有几十个属性存在，就会有一个包含几十个参数的构造器被Lombok注入到类中，这是不理智的行为；其次，构造器参数的顺序完全由Lombok所控制，我们并不能操控，只有当你需要调试时才发现有一个奇怪的“小强”在等着你；最后，在运行代码之前，所有JavaBean中的方法你只能想象他们长什么样子，你并不能看见。

4. 代码耦合度增加

当你使用Lombok来编写某一个模块的代码后，其余依赖此模块的其他代码都需要引入Lombok依赖，同时还需要在IDE中安装Lombok的插件。虽然Lombok的依赖包并不大，但就因为其中一个地方使用了Lombok，其余所有的依赖方都要强制加入Lombok的Jar包，这是一种入侵式的耦合，如果再遇上JDK版本问题，这将是一场灾难。

5.  违反了面向对象编程的封装特性

  直接用 IDE 或者 Lombok 插件（Java 项目）自动生成所有属性的 getter、setter 方法。实际上，这样的做法是非常不推荐的。它违反了面向对象编程的封装特性，相当于将面向对象编程风格退化成了面向过程编程风格。

总结

Lombok是一个优秀的Java类库，它采用了一种取巧的语法糖，简化了Java的编码，为Java代码的精简提供了一种方式，但在使用此代码库时，需要了解到Lombok并非一个标准的Java库。使用Lombok，会增加团队的技术债务，降低代码的可读性，增大代码的耦合度和调式难度。虽然在一定程度上Lombok减少了样板代码的书写，但也带来了一些未知的风险。

实际在使用的过程中需要根据团队的实际情况和业务情况等等多方面评审来使用。