扔了Lombok吧！MapStruct + Records才是正解！
原创大约 3 分钟
扔了Lombok吧！MapStruct + Records才是正解！
Lombok作为一个广受欢迎的Java开发工具，通过注解的方式帮助我们消除样板代码，提升开发效率。但随着项目的发展，它也带来了一些令人困扰的问题：
🧙♂️ Lombok的问题
- 代码可读性差 - 大量使用
@Data、@Builder等注解后，实际生成的代码变得不可见，增加了代码审查和维护的难度 - IDE支持不稳定 - 与IDE的集成经常出现问题，导致代码提示失效、编辑器卡顿等问题
- 运行时行为不可控 - 注解自动生成的方法（如equals、hashCode）可能产生意外的运行时行为
- 调试困难 - 由于代码是在编译时生成的，调试过程中难以追踪具体实现
这些问题导致团队在开发过程中经常遇到困惑："这个getter是从哪里来的？"、"为什么equals方法会这样实现？"。虽然表面上代码看起来简洁，但实际上增加了项目的维护成本。
🚪 是时候和 Lombok 分手了
有一天，我们决定移除Lombok! 然后，我们做了一个实验：
- 用Java Records替换
@Data。 - 用真正的构造函数替换
@Builder。 - 用 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，并最终真正地 掌控你自己的代码，然后睡个好觉，获得更多的头发！