使用RequiredArgsConstructor时如何保留无参构造器？

Question

在使用 Lombok 的 `@RequiredArgsConstructor` 时，会自动生成包含所有 final 字段和带有 `@NonNull` 注解字段的构造器，但不会生成无参构造器。这在某些框架（如 JPA、Jackson、反射实例化）中会导致问题，因为它们依赖无参构造器进行对象创建。常见问题是：当类缺少显式无参构造器且 `@RequiredArgsConstructor` 覆盖默认构造器后，反序列化或持久化操作失败。如何在保留 `@RequiredArgsConstructor` 功能的同时，确保无参构造器仍然存在？

Answer 1

如何在使用 Lombok 的 @RequiredArgsConstructor 时保留无参构造器？

1. 问题背景与现象描述

在 Java 开发中，Lombok 提供了 @RequiredArgsConstructor 注解来简化构造器的编写。该注解会为所有 final 字段以及被 @NonNull 标记的字段生成一个构造函数。

然而，Java 类默认提供的无参构造器会在显式定义任何构造器后被编译器移除。这意味着当 @RequiredArgsConstructor 被使用时，若类中没有显式声明无参构造器，则会导致：

• JPA 在实体映射时无法通过反射创建实例；
• Jackson 反序列化 JSON 到对象失败（报错如 "No suitable constructor found"）；
• 其他依赖默认构造器的框架（如 Spring Bean 实例化、测试框架等）出现异常。

因此，核心挑战是：如何在保留 @RequiredArgsConstructor 自动生成有参构造器的同时，确保无参构造器依然存在。

2. 深入分析：Lombok 构造器生成机制

Lombok 注解	生成构造器类型	是否覆盖默认构造器	适用场景
@NoArgsConstructor	无参构造器	否（除非强制）	ORM、序列化
@AllArgsConstructor	全参构造器	是	完全初始化对象
@RequiredArgsConstructor	必需参数构造器	是	DI、不可变对象

关键点在于：一旦生成了任何形式的构造器，Java 编译器就不会再提供默认无参构造器。而 Lombok 的处理是在编译期插入字节码，其行为遵循这一规则。

3. 解决方案一：显式添加 @NoArgsConstructor

最直接的方式是同时使用两个注解：

import lombok.*;

@RequiredArgsConstructor
@NoArgsConstructor
public class User {
    private final String id;
    @NonNull
    private String name;
    private String email; // 非 final，不参与 RequiredArgsConstructor
}

此时，Lombok 会生成两个构造器：

1. User(String id, String name) —— 来自 @RequiredArgsConstructor
2. User() —— 来自 @NoArgsConstructor

这满足了 Jackson、JPA 等框架对无参构造器的需求，同时也保留了依赖注入所需的构造器。

4. 解决方案二：控制访问级别与安全限制

在某些情况下，你可能希望无参构造器仅用于框架内部调用，而非公开使用。可以通过设置访问修饰符增强安全性：

@RequiredArgsConstructor
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class User {
    private final String id;
    @NonNull
    private String name;
}

这样，无参构造器对子类或同一包内可见，但外部代码不能随意调用，防止误用。这对于 JPA 实体尤其推荐，因为实体通常由持久层代理创建。

5. 解决方案三：结合 @Builder 使用的特殊情况

当使用 @Builder 时，默认也会生成一个私有的无参构造器。但如果搭配 @RequiredArgsConstructor，仍需注意是否暴露了正确的构造路径。

@Builder
@RequiredArgsConstructor
@NoArgsConstructor
public class Product {
    private final String sku;
    @NonNull
    private Double price;
}

上述组合可确保：

• Builder 模式可用；
• 必需字段通过构造器注入；
• 反序列化能正常工作。

6. 进阶策略：条件性生成与编译期验证

graph TD
    A[类定义] --> B{是否存在 final 或 @NonNull 字段?}
    B -- 是 --> C[生成 RequiredArgsConstructor]
    B -- 否 --> D[仅需无参构造器]
    C --> E[是否需要框架兼容?]
    E -- 是 --> F[添加 @NoArgsConstructor]
    E -- 否 --> G[仅保留 RequiredArgsConstructor]
    F --> H[输出两个构造器]

通过静态分析工具（如 SonarQube、ErrorProne）或自定义注解处理器，可以在编译期检查是否遗漏了必要的构造器，从而避免运行时错误。

7. 常见误区与最佳实践

• 误区一：认为 @Data 自动包含无参构造器 —— 实际上它包含的是 @RequiredArgsConstructor 的副作用，不保证无参存在；
• 误区二：忽略访问控制，将 @NoArgsConstructor 设为 public 导致业务逻辑绕过校验；
• 最佳实践：对于 JPA 实体，始终显式声明 @NoArgsConstructor(access = PROTECTED)；
• 最佳实践：结合 lombok.config 文件统一项目级构造器策略。

此外，可在项目根目录添加 lombok.config 文件以全局启用安全模式：

# lombok.config
lombok.noArgsConstructor.extraPrivate = true

8. 框架集成中的实际影响案例

假设有一个 Spring Data JPA 实体：

@Entity
@RequiredArgsConstructor
public class Order {
    @Id
    private final String orderId;
    @NonNull
    private BigDecimal amount;
}

尝试从数据库加载时抛出异常：

org.springframework.orm.jpa.JpaObjectRetrievalFailureException: 
Unable to instantiate result class [Order]: No default constructor for entity.

修复方式即添加：

@NoArgsConstructor(access = AccessLevel.PROTECTED)

这是生产环境中常见的“隐形陷阱”，尤其在团队协作和代码重构中容易被忽视。

9. 替代方案探讨：Record 与现代 Java 特性

从 Java 14+ 引入的 record 类型天然支持不可变性和紧凑语法，但它仅提供一个公共全参构造器，且不允许添加额外构造器。

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

虽然简洁，但 record 不适用于需要无参构造器的场景（如 JPA），因此在当前生态下，传统类 + Lombok 组合仍是更灵活的选择。

10. 总结性建议与未来趋势展望

随着微服务架构和云原生应用的发展，对象序列化与反序列化的频率显著增加。开发者必须更加关注构造器的完整性与兼容性。

推荐在团队内部建立编码规范，明确以下原则：

• 所有需被框架实例化的类必须显式声明无参构造器；
• 优先使用 @NoArgsConstructor(access = PROTECTED) 而非 public；
• 结合 IDE 插件（如 Lombok Plugin）实时提示缺失构造器；
• 在 CI 流程中加入字节码分析步骤，检测构造器完整性。

未来的 Lombok 版本可能会引入更智能的合并策略，例如自动推断是否需要补充无参构造器，但在目前阶段，显式声明仍是可靠之道。