扔了 Lombok 吧，MapStruct + Records 更爽！

Lombok作为一个广受欢迎的Java开发工具，通过注解的方式帮助我们消除样板代码，提升开发效率。但随着项目的发展，它也带来了一些令人困扰的问题。

🧙‍♂️ Lombok的问题

• • 代码可读性差 - 大量使用@Data、@Builder等注解后，实际生成的代码变得不可见，增加了代码审查和维护的难度
• • IDE支持不稳定 - 与IDE的集成经常出现问题，导致代码提示失效、编辑器卡顿等问题
• • 运行时行为不可控 - 注解自动生成的方法（如equals、hashCode）可能产生意外的运行时行为
• • 调试困难 - 由于代码是在编译时生成的，调试过程中难以追踪具体实现

这些问题导致团队在开发过程中经常遇到困惑："这个getter是从哪里来的？"、"为什么equals方法会这样实现？"。虽然表面上代码看起来简洁，但实际上增加了项目的维护成本。

🚪 是时候和 Lombok 分手了

有一天，我们决定移除Lombok! 然后，我们做了一个实验：

1. 1. 用Java Records替换 @Data。
2. 2. 用真正的构造函数替换 @Builder。
3. 3. 用 MapStruct 替换那些笨重的 ModelMapper/Lombok DTO 组合。

结果怎样？一切都变好了！

🧾 为什么 Java Records > Lombok @Data

Lombok:

@Data
public class User {
  private String name;
  private int age;
}

对比

Java Records:

public record User(String name, int age) {}

哪一个更具可读性？更类型安全？更适合不变性？

Records:

• • 默认是 final 且不可变的。
• • 生成构造函数、equals、hashCode 和 toString——所有这些都是可见的。
• • 与 IDE 和序列化工具配合良好。

额外好处：你不需要仅仅为了写一个有两个字段的类就引入一个外部依赖。

🎯 MapStruct：真正的映射，而非猜测

现在介绍另一位英雄：MapStruct。

我们曾经有这样的类：

class UserEntity {
  private String name;
  private int age;
  // 通过 Lombok 实现的 setters 和 getters
}

class UserDTO {
  private String name;
  private int age;
  // 通过 Lombok 实现的 setters 和 getters
}

然后是：

UserDTO dto = modelMapper.map(userEntity, UserDTO.class);

优雅，对吧？直到它不再优雅。

• • 字段无声无息地停止了映射。
• • 调试变成了一场猜谜游戏。
• • 嵌套映射变成了噩梦。

使用 MapStruct，我们这样做：

@Mapper
public interface UserMapper {
  UserDTO toDto(UserEntity user);
}

编译时检查。清晰。明确。快速。

没有反射，没有运行时意外。只有可预测、可读、真正的映射。

🎁 我们获得了什么？

• • 减少了 80% 的样板代码。 真的。
• • 零 IDE 问题。 再也没有奇怪的自动补全 bug。
• • 更好的入职体验。 新来的开发者不需要 Lombok 解码器。
• • 编译时安全。 在映射错误在生产环境中造成麻烦之前就捕捉到它们。

🧠 小结

Lombok 在它那个时代是很出色的，但是 Java 在不断进化了，是时候抛弃它了！

• • 用 Records 替换 @Data。
• • 放弃 @Builder 并使用构造函数（如果需要，可以使用 MapStruct 的构建器）。
• • 用 MapStruct 替换 ModelMapper

你将会编写更少的注解，调试更少的 Bug，并最终真正地 掌控你自己的代码，然后睡个好觉，获得更多的头发！