Lombok的利与弊

关注

原创最新推荐文章于 2026-08-05 10:55:36 发布 1.3k 阅读 AI 写同款· GEO 优化 ›

Lombok（原理，Lombok安装，Lombok注解）系列文章目录目录系列文章目录文章目录前言一、pandas是什么？二、使用步骤 1.引入库 2.读入数据总结提示：这里可以添加系列文章的所有文章的目录，目录需要自己手动添加例如：第一章 Python 机器学习入门之pandas的使用提示：写完文章后，目录可以自动生成，如何生成可参考右边的帮助文档文章目录系列文章目录前言一、pandas是什么？二、使用步骤 1.引入库 2.读入数据总结前言提示：这里可以添加本文要.. 阅读详情

使用Lombok

整体定位

没有太多技术上的东西，主要就是减少代码。或者说，将以前写的常用且重复的代码用注解的形式“简写“一下。如给属性添加Setter，Getter方法，无参构造方法，全参构造方法，hashCode()，equals()方法，toString()等等。

import

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.12</version>
</dependency>

常用注解

Lombok features
最常用的有：@Data，@Setter，@Getter，@NoArgsConstructor。
其作用不再赘述了，直接看上面官网文档就知道了。

其他好用的注解

@Slf4j

作用在类上，可以直接取代：

private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(XXX.class);

@Builder

自动生成建造者模式的方法。

缺点

这位老哥总结的很详细：作为一名资深后端开发，为什么从不推荐别人使用Lombok，谈谈我的看法…
总结一下，有以下几点：

侵入性太强
因为Lombok注解如@Getter（），IDE在代码提示阶段就会报错：stu.getName()找不到该方法，需要下载相应的插件才可以消除错误提示。
在多人协作开发过程中，如果有一个人使用lombok开发，那么其他人必然也需要装，不然整个项目编译不能成功。
代码跟踪不友好
因为用注解的形式省去了Setter，Getter等方法，在代码跟踪时（如查看Setter的所有调用位置）就会”断链“。
版本兼容问题
私以为这个问题不是那么严重。
1）和Java的兼容性问题由Java本身的向后兼容性保证。
2）团队队员之间的lombok应该由父POM统一管理，而不是各个队员自己指定。)
3）和第三方依赖中的lombok版本冲突问题，属于项目”依赖冲突“的范畴，和任何其他jar包的依赖冲突一样，应该仔细进行依赖审查，exclude掉子依赖的lombok
封装性问题
即使对于private属性，@Data or @Setter注解会生成public的Setter，其实这个问题也不算是问题，看到网上老哥已经给出解决方案

@Setter(AccessLevel.PROTECTED)

即这样生成了private级别的Setter方法，即维持了封装性。

不懂误用的问题
如，不知道@Data是以下三个注解的合成：

来源：lombok的Data注解
PS：
1）关于lombok关于构造器的注解，这篇写的挺好《Lombok 实战 —— @NoArgsConstructor, @RequiredArgsConstructor, @AllArgsConstructor》)
2）其实具体的lombok的作用，大家可以去看编译之后的.class，对比原来的.java就明白到底什么作用了
回到”不懂误用“的问题，如果使用者不知道Data覆写了hashCode()方法，同时又使用了Set/Map等，就有可能造成严重的后果。

到底用还是不用

知道发生了什么，小而独立的业务项目使用

以上弊端分析可以看到，最大的弊端：

不懂注解给类带来了哪些改变，或者说只注意到增加了Setter/Getter/Constructor
侵入性太强，绑架队友
代码跟踪困难

仔细分析下来，不是不可以用。最重要的一点：不要因为使用一个偷懒工具造成bug，在了解注解给代码带来了什么改变的前提下，小团队（特别个人独立开发项目）是可以用的。

大项目，基础的工具包不要用

如果是大项目，协同的人太多，不合适。
同样地，向外提供的工具包同样不要依赖lombok，虽然在之前的分析中，认为依赖冲突是客户端自己应该解决的问题，但是能不造成麻烦就不要造成，谁也不能保证他们就能正确排包。

实用性的建议

在最简单的Java Bean上使用@Data
在实际使用中，@Data应该是使用最广泛的注解，它的确也带来了很大的便利。如果非要使用的话，建议把它用在最简单的Java Bean上。
1）这个bean的private属性对封装性没有那么高要求（生成public Setter也没事）
2）这个bean对象不会作为Set，Map参数（泛型）传入（因为hashCode()已经被重写，很危险）