Java 开发者几乎都用过 Lombok。一个Data注解省去了几十行 getter、setter、equals、hashCode、toString一个Slf4j连 Logger 声明都免了。它让代码变得干净利落开发效率肉眼可见地提升。但我在多个项目中见过 Lombok 引发的“血案”JPA 实体栈溢出、JSON 序列化字段丢失、线上日志刷爆磁盘。Lombok 确实是一把双刃剑用对了效率翻倍用错了就是灾难。效率翻倍的一面Lombok 最大的价值是消除样板代码。以RequiredArgsConstructor为例它能为所有final字段生成构造器配合 Spring 的构造器注入代码从java复制下载Service public class OrderService { private final OrderRepository orderRepository; private final InventoryClient inventoryClient; public OrderService(OrderRepository orderRepository, InventoryClient inventoryClient) { this.orderRepository orderRepository; this.inventoryClient inventoryClient; } }变成java复制下载Service RequiredArgsConstructor public class OrderService { private final OrderRepository orderRepository; private final InventoryClient inventoryClient; }字段一旦增减构造器自动更新不会漏改。再加上Builder链式构建、Slf4j日志注入编码速度确实能提升一个档次。灾难的一面三个典型场景场景一Data用在 JPA 实体上Data会生成equals和hashCode默认使用所有非静态、非瞬态字段。如果两个实体互相引用比如订单和订单项hashCode会递归调用直接栈溢出。更常见的是JPA 实体通常有自增 ID在 ID 为 null 时equals比较的是所有字段两个新建的“空对象”可能被判定相等放入 Set 后行为诡异。正确做法是实体类只加Getter、Setterequals和hashCode基于业务主键手动实现或者用EqualsAndHashCode(onlyExplicitlyIncluded true)只包含 ID 字段。场景二Builder与 Jackson 反序列化冲突Builder生成的构建器很好用但它会生成一个全参构造器同时默认的无参构造器被覆盖。Jackson 反序列化时需要一个无参构造器或JsonCreator结果直接报InvalidDefinitionException。解决办法是同时加上NoArgsConstructor和AllArgsConstructor或者用Jacksonized。但很多人不知道线上接口突然 500排查半天才发现是 Lombok 的“锅”。场景三ToString触发懒加载和敏感信息泄露在 JPA 实体上直接Data或ToString打印日志时如果实体有关联集合且处于懒加载状态toString会触发额外的 SQL 查询轻则性能下降重则LazyInitializationException。更危险的是用户实体里包含密码、身份证号ToString会一股脑打出来日志文件成了敏感信息泄露的重灾区。正确做法是ToString(exclude {password, idCard})或者干脆不生成 toString。还有这些隐性成本Lombok 是编译期注解处理器代码在 IDE 里看起来正常但编译后的 class 文件才包含生成的方法。如果团队成员没有安装 Lombok 插件打开项目就是满屏红。升级 JDK 版本时Lombok 也可能因为内部 API 变更而失效导致构建失败。此外调试时想看某个 getter 的实现却发现源码里根本不存在只能反编译 class 文件。如何用好这把剑第一明确使用边界。DTO、VO 可以用Data实体类慎用领域对象只加Getter。第二显式控制生成内容。EqualsAndHashCode只包含业务主键ToString排除敏感字段Builder配合NoArgsConstructor和AllArgsConstructor。第三团队统一规范。在项目 README 中写明 Lombok 使用约定CI 中确保编译通过避免有人本地正常、线上构建失败。第四不要过度依赖。如果生成逻辑复杂宁可手写也不要为了少写几行代码而埋下隐患。Lombok 本身没有错错的是不加思考地滥用。它像一把锋利的手术刀在懂解剖的人手里能精准切除冗余在不了解结构的人手里则会割伤自己。用之前多问一句这个注解会生成什么会不会影响序列化、持久化、日志想清楚了它才是真正的效率利器。 为什么说Lombok是一把双刃剑？用对了效率翻倍，用错了灾难
Java 开发者几乎都用过 Lombok。一个Data注解省去了几十行 getter、setter、equals、hashCode、toString一个Slf4j连 Logger 声明都免了。它让代码变得干净利落开发效率肉眼可见地提升。但我在多个项目中见过 Lombok 引发的“血案”JPA 实体栈溢出、JSON 序列化字段丢失、线上日志刷爆磁盘。Lombok 确实是一把双刃剑用对了效率翻倍用错了就是灾难。效率翻倍的一面Lombok 最大的价值是消除样板代码。以RequiredArgsConstructor为例它能为所有final字段生成构造器配合 Spring 的构造器注入代码从java复制下载Service public class OrderService { private final OrderRepository orderRepository; private final InventoryClient inventoryClient; public OrderService(OrderRepository orderRepository, InventoryClient inventoryClient) { this.orderRepository orderRepository; this.inventoryClient inventoryClient; } }变成java复制下载Service RequiredArgsConstructor public class OrderService { private final OrderRepository orderRepository; private final InventoryClient inventoryClient; }字段一旦增减构造器自动更新不会漏改。再加上Builder链式构建、Slf4j日志注入编码速度确实能提升一个档次。灾难的一面三个典型场景场景一Data用在 JPA 实体上Data会生成equals和hashCode默认使用所有非静态、非瞬态字段。如果两个实体互相引用比如订单和订单项hashCode会递归调用直接栈溢出。更常见的是JPA 实体通常有自增 ID在 ID 为 null 时equals比较的是所有字段两个新建的“空对象”可能被判定相等放入 Set 后行为诡异。正确做法是实体类只加Getter、Setterequals和hashCode基于业务主键手动实现或者用EqualsAndHashCode(onlyExplicitlyIncluded true)只包含 ID 字段。场景二Builder与 Jackson 反序列化冲突Builder生成的构建器很好用但它会生成一个全参构造器同时默认的无参构造器被覆盖。Jackson 反序列化时需要一个无参构造器或JsonCreator结果直接报InvalidDefinitionException。解决办法是同时加上NoArgsConstructor和AllArgsConstructor或者用Jacksonized。但很多人不知道线上接口突然 500排查半天才发现是 Lombok 的“锅”。场景三ToString触发懒加载和敏感信息泄露在 JPA 实体上直接Data或ToString打印日志时如果实体有关联集合且处于懒加载状态toString会触发额外的 SQL 查询轻则性能下降重则LazyInitializationException。更危险的是用户实体里包含密码、身份证号ToString会一股脑打出来日志文件成了敏感信息泄露的重灾区。正确做法是ToString(exclude {password, idCard})或者干脆不生成 toString。还有这些隐性成本Lombok 是编译期注解处理器代码在 IDE 里看起来正常但编译后的 class 文件才包含生成的方法。如果团队成员没有安装 Lombok 插件打开项目就是满屏红。升级 JDK 版本时Lombok 也可能因为内部 API 变更而失效导致构建失败。此外调试时想看某个 getter 的实现却发现源码里根本不存在只能反编译 class 文件。如何用好这把剑第一明确使用边界。DTO、VO 可以用Data实体类慎用领域对象只加Getter。第二显式控制生成内容。EqualsAndHashCode只包含业务主键ToString排除敏感字段Builder配合NoArgsConstructor和AllArgsConstructor。第三团队统一规范。在项目 README 中写明 Lombok 使用约定CI 中确保编译通过避免有人本地正常、线上构建失败。第四不要过度依赖。如果生成逻辑复杂宁可手写也不要为了少写几行代码而埋下隐患。Lombok 本身没有错错的是不加思考地滥用。它像一把锋利的手术刀在懂解剖的人手里能精准切除冗余在不了解结构的人手里则会割伤自己。用之前多问一句这个注解会生成什么会不会影响序列化、持久化、日志想清楚了它才是真正的效率利器。