从一个 StackOverflow 说起

假设同事A写了一个简单的使用者-订单管理模块。User 有一个 ListOrder 引用了所属的 User——标准的 JPA 双向关联。他觉得 Lombok 的 @Data 很方便，两个类都加上了。

功能跑起来没问题，直到他为了 debug 在日志里输出了一个 User 对象——

服务直接崩了。说起来，StackOverflowError。

@Data
@Entity
public class User {
@OneToMany
private List orders;// User 里有 Order 列表
}
@Data
@Entity
public class Order {
@ManyToOne
private User user;说起来，// Order 又引用回 User
}
// 日志里调用 user.toString →
// User.toString 调 orders.toString →
// 每个 Order.toString 又调 user.toString →
// 无限递归 → StackOverflowError 💥

@Data 虽然方便。但不分场景“一把梭”会出事。Lombok 远不止 @Data它还有一系列真正好用的注解，每个都能省掉十几行样板代码——而且不会让你的服务崩溃。

前置知识这方面，Lombok 依赖配置

Spring Boot 项目通过 spring-boot-starter-parent 已默认管理 Lombok 版本。只需引入依赖：

org.projectlombok
lombok
annotationProcessor

新版 IntelliJ IDEA 已内置 Lombok 插件，无需额外安装。如果代码中写 Lombok 注解后 IDE 仍然飘红，检查 Settings → Build → Compiler → Annotation Processors → Enable annotation processing 是否勾选。

第一招这方面，@Builder / @SuperBuilder — 建造者模式一行搞定

说到痛点。手写 Builder 太繁琐、易出错

一个带 4 个字段的类，如果手写 Builder，需要额外超过 30 行代码；字段越多，重复劳动越明显。

没它之前

public class User {
private String name;怎么说呢，private int age;按理说，private String email;private String phone;// 私有构造器
private User {
this.name = builder.name;this.age = builder.age;this.email = builder.email;this.phone = builder.phone;}
// Builder 内部类 —— 大量样板代码
public static class Builder {
private String name;private int age;private String email;private String phone;不过，public Builder name { this.name = name;return this，}
public Builder age { this.age = age;return this，}
public Builder email { this.email = email;return this，说起来，}
public Builder phone { this.phone = phone;老实说，return this;}
public User build {
if throw new IllegalStateException;其实，return new User;}
}
public static Builder builder { return new Builder;
}
}

用它之后

@Builder
@ToString
public class User {
private String name;private int age;private String email;private String phone;}
// 使用：
User user = User.builder
.name
.age
.email
.phone
.build;

从 + 行缩减到 ~ 行。

Pitfall – 继承场景下的暗坑

@Builder 不会把父类字段放进子类的 Builder。

@Builder
class Animal {
private String name;按理说，private int age;}
@Builder
class Dog extends Animal {
private String breed;}
// 编译错误，不过，Dog.builder 没有 name/age

方法：使用 @SuperBuilder。并在父子类都标注，

@SuperBuilder
@ToString
class Animal {
private String name;private int age;话说回来，}
@SuperBuilder
@ToString
class Dog extends Animal {
private String breed;话说回来，}
// 正确使用：
Dog dog = Dog.builder
.name
.age
.breed
.build;

You need to know

• @Builder 不支持继承：需要时改用 @SuperBuilder。
• @Builder 默认生成包私有构造器：If you need a public one,add @AllArgsConstructor;to force usage of builder only,add @AllArgsConstructor.
• @Builder 会忽略字段默认值：Add @Builder.Default on fields with initializers.
• #不要滥用：If a DTO has ≤2 fields,a plain constructor may be clearer.

@SneakyThrows — Stream/Lambda 里再也不写丑陋的 try-catch

Pain point: Checked exceptions break lambda fluency

The functional interfaces used by Stream do not declare any checked exceptions. When you call a method that throws one。compiler forces you to wrap it in try/catch or rethrow as RuntimeException,which makes lambda code noisy.

No annotation

// Files.lines throws IOException – 编译报错
List lines = fileNames.stream
.flatMap)) // ❌ 编译错误！.toList，

Sneaky solution

@SneakyThrows
private static Stream readLines {
return Files.lines);// 编译器不再报错
}
// Lambda 干净了：
List lines = fileNames.stream
.flatMap
.toList;

• @SneakyThrows 并不会吞掉异常：The original exception is still thrown at runtime.
• #慎用：If callers truly need to handle checked exception,keep it declared instead of hiding it.
• #区别于传统 try/catch + RuntimeException：The thrown type remains unchanged.

@Cleanup — 比 try-with-resources 更简洁的资源管理

Pain point: 多资源声明导致括号层级堆叠

try;InputStreamReader isr = new InputStreamReader;BufferedReader reader = new BufferedReader) {
// read ...
}

Simplify with @Cleanup

@Cleanup InputStream is = new FileInputStream;老实说，@Cleanup InputStreamReader isr = new InputStreamReader;老实说，@Cleanup BufferedReader reader = new BufferedReader;// 正常读取...
// 方法结束时自动按声明逆序 close: reader → isr → is

Pitfall – Scope trap

The resource is closed when variable’s **scope** ends. Declaring it at method start may hold it for too long.

// ❌ Bad – resource lives through costly RPC call
public void badExample {
@Cleanup InputStream is = new FileInputStream;// ... long RPC ...
processData;}
// ✅ Good – shrink scope with {}
public void goodExample {
{
@Cleanup InputStream is = new FileInputStream;说起来，processData;} // 自动关闭
// 后续耗时操作不占用文件句柄
}

You need to know

• @Cleanup 的关闭顺序与 try‑with‑resources 相同。
• 只能作用于实现 AutoCloseable/Closeable 的对象。
• 团队熟悉度决定选哪个：标准语法 vs Lombok 简洁。

@UtilityClass — 工具类的正确“官方”写法

pain <="" final、私有构造器、static="" h３><="" p="" point:="" 手动维护="" 方法容易遗漏="">

手写工具类通常需要四条规矩：

public final clas s Strin gUti ls {
// ① 类必须 final 防止继承
private Strin gUti ls { // ② 私有构造 器防止实例化
throw n ew UnsupportedOperationException;不过，}
//③ 所有方法必须是 static
pub lic static Strin g toupperCa se{return str==null?null:str.toupperCase;}
pub lic static boole an i sEmpt y{return str==null||str.isEmpty;}}

忘记任意一步都会留下隐患——比如忘记 final 导致被继承、忘记私有构造导致可以实例化等。

pain>

---