Java开发为什么不要在项目里乱用 Lombok？

现在的 Java 开发，Lombok 几乎成了标配。

只要加上@Data，Getter/Setter、toString、equals/hashCode全部搞定，代码瞬间清爽，再也不用写那一堆冗长的样板代码了。

很多开发者（尤其是新手）对 Lombok 趋之若鹜，甚至到了“无 Lombok 不写代码”的地步。

但是，作为一个在代码坑里摸爬滚打多年的老兵，我劝你：在项目里乱用 Lombok，真的会出事。

@Data 下的 hashCode 陷阱

这是最隐蔽、杀伤力最大的一个坑。

很多时候，我们为了方便，直接在实体类上甩一个 @Data 注解。@Data包含了@EqualsAndHashCode，它会自动生成 equals 和 hashCode 方法。

问题来了： Lombok 默认生成 equals 和 hashCode 时，会使用所有非静态字段。

如果你的实体类中有 List、Set 等集合类型的字段，这会导致严重的性能问题，甚至引发死循环。

场景复现：

@Data
public class Order {
    private String orderId;
    private List<String> items; // 这是一个 List
}

当你把 Order 对象存入 HashMap 或者 HashSet 时，或者调用order.equals()时，Lombok 生成的 hashCode 方法会遍历 items 列表。

• 如果 items 列表很大，计算 hashCode 会非常慢。
• 更可怕的是，如果 items 列表里又引用了 Order 对象本身（循环依赖），程序就会直接抛出 StackOverflowError 崩溃！

避坑建议：

一定要显式指定@EqualsAndHashCode.Exclude，排除掉集合类型的字段，或者只使用主键（ID）来生成 hashCode。

@Data
public class Order {
    private String orderId;
    
    @EqualsAndHashCode.Exclude
    private List<String> items; // 排除集合字段
}

@AllArgsConstructor 的“参数顺序问题”

为了省去写构造函数的时间，很多人喜欢用@AllArgsConstructor。

这在字段较少、且字段类型不重复时还好。但一旦你的类里有几个相同类型的字段，问题就开始了。

场景复现：

@AllArgsConstructor
public class User {
    private String username;
    private String nickname;
    private Integer age;
}

Lombok 生成的构造函数顺序是严格按照字段定义顺序来的：new User(“张三”, “小三”, 18)。

这时候，如果你手抖调整了一下代码顺序（这在重构时非常常见）：

@AllArgsConstructor
public class User {
    private String nickname; // 顺序换了
    private String username;
    private Integer age;
}

此时，构造函数的签名变了！原来的 username 位置现在变成了 nickname。

如果你项目里其他地方还在用 new User(“张三”, “小三”, 18)，编译器不会报错，但数据已经存乱了！张三变成了昵称，小三变成了用户名。这种逻辑错误在运行时极难排查。

避坑建议：

1. 尽量少用@AllArgsConstructor。
2. 推荐使用@Builder模式，链式调用，不仅清晰，而且不怕字段顺序调整：
   User.builder().username("张三").nickname("小三").age(18).build();

破坏封装，@Getter 的滥用

Lombok 的@Getter虽然方便，但它经常会诱导我们破坏面向对象的封装性。

面向对象的核心原则是：对象应该管理自己的状态。但 Lombok 让我们习惯了把所有字段都暴露出去。

场景复现：

@Data
public class ShoppingCart {
    private List<String> items = new ArrayList<>();
    
    public void addItem(String item) {
        items.add(item);
    }
}

看似没问题，但@Data自动生成了getItems()方法，返回的是内部集合的引用。

外部调用者可以这样写：

cart.getItems().clear(); // 直接清空了购物车！

这就意味着，外部代码可以绕过 ShoppingCart 类的管控，直接修改内部数据。这是严重的封装破坏，可能导致不可预期的 Bug。

避坑建议：

1. 不要无脑@Data。
2. 对于集合类字段，不要提供直接的 getter，或者只返回不可修改的视图：

public class ShoppingCart {
    private List<String> items = new ArrayList<>();
    
    public List<String> getItems() {
        return Collections.unmodifiableList(items); // 返回只读视图
    }
}

结语

Lombok 确实是个好东西，它让我们从繁琐的样板代码中解脱出来。

但 “能力越大，责任越大”。

如果不理解 Lombok 背后的生成机制，盲目地使用@Data、@AllArgsConstructor，最终反而会造成一些问题。

可以记住这三点：

1. 集合字段小心 hashCode 死循环。
2. 多参数构造函数小心参数顺序错乱，优先用 @Builder。
3. 不要为了省事暴露内部状态，注意封装性。

以上关于Java开发为什么不要在项目里乱用 Lombok？的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。