阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 toutiao.com/i6884399145390440964 「Java实用技术」欢迎转载，保留摘要，谢谢！

• JDK 版本问题
• 胁迫使用
• 可读性差
• 代码耦合度增加
• 得不偿失

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

经常在其它各个地方在说公司禁止使用Lombok，我一直不明白为什么不让用，今天看到一篇文章列举了一下“缺点”，这里我只想狠狠地反驳，看到列举的理由我竟无言以对。

对 Lombok 不了解的胖友，可以阅读艿艿写的 http://www.iocoder.cn/Spring-Boot/Lombok/ 文章

想要了解 Lombok 在实际项目中的使用，可以看 https://github.com/YunaiV/ruoyi-vue-pro 项目

JDK 版本问题

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

我的反驳：很多公司一旦确定JDK版本在很长的时间都不会改变（比如银行项目很多都在用jdk1.6，你问他愿意升级到jdk11不？），现在都出到14版本了，你看有多少公司会升级！如现在很多公司都在用JDK1.8，任你出到JDK14，我依然继续使用JDK1.8，等你出到JDK20时我相信Lombok肯定会支持更高的版本，那时兼容问题将不存在。

胁迫使用

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

我的反驳：你装不装Lombok 插件不是你喜不喜欢，不是由你个人意愿决定的，这是工作，公司要求怎么做就要怎么做，这是规定。Lombok是一个非常简单的知识点，十分钟就能上手使用，你却抱怨要花费时间学习，作为程序员不是无时无刻都在学习吗，你有这种抱怨只能你放弃程序员这个工作吧！

可读性差

Lombok 隐藏了 JavaBean 封装的细节，如果你使用 @AllArgsConstructor 注解，它将提供一个巨型构造器，让外界有机会在初始化对象时修改类中所有的属性。

首先，这是极其不安全的，因为类中某系属性我们是不希望被修改的；

另外，如果某个类中有几十个属性存在，就会有一个包含几十个参数的构造器被 Lombok 注入到类中，这是不理智的行为；

其次，构造器参数的顺序完全由 Lombok 所以制，我们并不能操控，只有当你需要调试时才发现有一个奇怪的 “小强” 在等着你；

最后，在运行代码之前，所有 JavaBean 中的方法你只能想象他们长什么样子，你并不能看见。

我的反驳：不满意@AllArgsConstructor的做法你可以使用@Builder啊，这个支持你任意顺序任意数量的创建对象，你不了解Lombok的其它用法就说它不好。你要看JavaBean中的方法？它有啥好看的，Getter和Setter方法有啥好看的，你不知道Getter和Setter方法长什么样吗？实在不明白有什么好看的？

代码耦合度增加

当你使用 Lombok 来编写某一个模块的代码后，其余依赖此模块的其他代码都需要引入 Lombok 依赖，同时还需要在 IDE 中安装 Lombok 的插件。

虽然 Lombok 的依赖包并不大，但就因为其中一个地方使用了 Lombok，其余所有的依赖方都要强制加入 Lombok 的 Jar 包，这是一种入侵式的耦合，如果再遇上 JDK 版本问题，这将是一场灾难。

我的反驳：我们在使用其它框架时，那框架引入了不计其数的包，现在要引入一个很小的包都在斤斤计较，Lombok这么好用，几乎所有项目都会使用到，这还需要强制引入吗，我们自觉的都会在maven的parent依赖中统一引入了。

得不偿失

使用 Lombok，一时觉得很爽，但它却污染了你的代码，破坏了 Java 代码的完整性，可读性和安全性，同时还增加的团队的技术债务，这是一种弊大于利，得不偿失的操作。如果你确实想让自己的代码更加精炼，同时又兼顾可读性和编码效率，不妨使用主流的 Scala 或 Kotlin 这一基于 JVM 的语言。

我的反驳：破坏了完整性？加上臃肿的Getter&Setter你却嫌弃臃肿，不加你又说破坏代码的完整性，你想怎么做。增加团队的技术债务？学个Lombok十分钟的事情，有什么好增加的。要使用Kotlin? 一般公司都没有这么激进吧，现在Kotlin很多配套东西在企业中使用还不成熟吧。

大家还有什么不同观点可以互相讨论。