主要用注解方式来简化 Java 实体类的书写，使代码更简洁清晰，所需依赖，例如：
<dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.16.20</version> <scope>provided</scope></dependency>
@Data 注解在类上，会为类的所有属性自动生成 setter/getter、equals、canEqual、hashCode、toString 方法 @ToString、@EqualsAndHashCode、@Getter/@Setter、@RequiredArgsConstructor 的所有特性 （），如为 final 属性，则不会为该属性生成 setter 方法。
@Getter/@Setter 注解，此注解在属性上，可以为相应的属性自动生成 Getter/Setter 方法
@NonNull 该注解用在属性或构造器上，Lombok 会生成一个非空的声明，可用于校验参数，能帮助避免空指针。
@Cleanup 该注解能帮助我们自动调用 close() 方法，很大的简化了代码，例如：
import lombok.Cleanup;
import java.io.*;
public class CleanupExample { public static void main(String[] args) throws IOException { @Cleanup InputStream in = new FileInputStream(args[0]);
@Cleanup OutputStream out = new FileOutputStream(args[1]);
byte[] b = new byte[10000];
while (true) { int r = in.read(b);
if (r == -1) break;
out.write(b, 0, r);
}
}
}@EqualsAndHashCode 默认情况下，会使用所有非静态（non-static）和非瞬态（non-transient）属性来生成 equals 和 hasCode，也能通过 exclude 注解来排除一些属性。示例：
import lombok.EqualsAndHashCode;
@EqualsAndHashCode(exclude={"id", "shape"})
public class EqualsAndHashCodeExample {
private transient int transientVar = 10;
private String name;
private double score;
private Shape shape = new Square(5, 10);
private String[] tags;
private int id;
public String getName() {
return this.name;
}
@EqualsAndHashCode(callSuper=true)
public static class Square extends Shape {
private final int width, height;
public Square(int width, int height) {
this.width = width;
this.height = height;
}
}
}@ToString 注解，Lombok 会生成一个 toString()方法，默认情况下，会输出类名、所有属性（会按照属性定义顺序），用逗号来分割。通过将 includeFieldNames 参数设为 true，就能明确的输出 toString()属性。这一点是不是有点绕口，通过代码来看会更清晰些。示例：
import lombok.ToString;
@ToString(exclude="id")
public class ToStringExample {
private static final int STATIC_VAR = 10;
private String name;
private Shape shape = new Square(5, 10);
private String[] tags;
private int id;
public String getName() { return this.getName();
}
@ToString(callSuper=true, includeFieldNames=true)
public static class Square extends Shape {
private final int width, height;
public Square(int width, int height) {
this.width = width;
this.height = height;
}
}
}@NoArgsConstructor, @RequiredArgsConstructor and @AllArgsConstructor 无参构造器、部分参数构造器、全参构造器。Lombok 没法实现多种参数构造器的重载。
Lombok 的优缺点
优点：
能通过注解的形式自动生成构造器、getter/setter、equals、hashcode、toString 等方法，提高了一定的开发效率
让代码变得简洁，不用过多的去关注相应的方法
属性做修改时，也简化了维护为这些属性所生成的 getter/setter 方法等
缺点：
不支持多种参数构造器的重载
虽然省去了手动创建 getter/setter 方法的麻烦，但大大降低了源代码的可读性和完整性，降低了阅读源代码的舒适度
总结
Lombok 虽然有很多优点，但 Lombok 更类似于一种 IDE 插件，项目也需要依赖相应的 jar 包。Lombok 依赖 jar 包是因为编译时要用它的注解，为什么说它又类似插件？因为在使用时，eclipse 或 IntelliJ IDEA 都需要安装相应的插件，在编译器编译时通过操作 AST（抽象语法树）改变字节码生成，变向的就是说它在改变 java 语法。它不像 spring 的依赖注入或者 mybatis 的 ORM 一样是运行时的特性，而是编译时的特性。这里我个人最感觉不爽的地方就是对插件的依赖！因为 Lombok 只是省去了一些人工生成代码的麻烦，但 IDE 都有快捷键来协助生成 getter/setter 等方法，也非常方便。
知乎上有位大神发表过对 Lombok 的一些看法：
这是一种低级趣味的插件，不建议使用。JAVA 发展到今天，各种插件层出不穷，如何甄别各种插件的优劣？能从架构上优化你的设计的，能提高应用程序性能的 ， 实现高度封装可扩展的...， 像 lombok 这种，像这种插件，已经不仅仅是插件了，改变了你如何编写源码，事实上，少去了代码你写上去又如何？ 如果 JAVA 家族到处充斥这样的东西，那只不过是一坨披着金属颜色的屎，迟早会被其它的语言取代。
虽然话糙但理确实不糙，试想一个项目有非常多类似 Lombok 这样的插件，个人觉得真的会极大的降低阅读源代码的舒适度。
虽然非常不建议在属性的 getter/setter 写一些业务代码，但在多年项目的实战中，有时通过给 getter/setter 加一点点业务代码，能极大的简化某些业务场景的代码。所谓取舍，也许就是这时的舍弃一定的规范，取得极大的方便。
我现在非常坚信一条理念，任何编程语言或插件，都仅仅只是工具而已，即使工具再强大也在于用的人，就如同小米加步枪照样能赢飞机大炮的道理一样。结合具体业务场景和项目实际情况，无需一味追求高大上的技术，适合的才是王道。
Lombok 有它的得天独厚的优点，也有它避之不及的缺点，熟知其优缺点，在实战中灵活运用才是王道。
参考：
https://projectlombok.org/features/
https://github.com/rzwitserloot/lombok?spm=a2c4e.11153940.blogcont59972.5.2aeb6d32hayLHv
https://www.zhihu.com/question/42348457
https://blog.csdn.net/ghsau/article/details/52334762
转载：https://www.cnblogs.com/heyonggang/p/8638374.html
支付宝领红包