Java记录类作DTO时如何处理null校验？

Question

在使用Java记录类（record）作为DTO时，如何有效处理字段的null校验是一个常见难题。由于记录类默认仅生成基于参数顺序的构造函数，且字段为final，无法在内部直接通过setter进行校验。若不加控制，客户端传入null值可能导致空指针异常或数据不一致。那么，如何在保持记录类不可变特性的前提下，在对象创建阶段就对字段实施非空校验？

Answer 1

Java记录类（record）作为DTO时的null校验深度解析

1. 问题背景与核心挑战

自Java 14引入记录类（record）以来，其简洁语法和不可变语义使其成为构建数据传输对象（DTO）的理想选择。然而，记录类默认仅生成一个基于参数顺序的公共构造函数，且所有字段均为final，无法通过传统setter进行后期校验。

当客户端传入null值时，若未加约束，极易引发NullPointerException或导致业务逻辑异常。因此，在保持不可变性的前提下，如何在对象创建阶段完成字段的非空校验，成为关键难题。

2. 常见技术误区与陷阱

• 误用Lombok注解：试图在record上使用@Data或@NonNull，但Lombok对record支持有限，可能导致编译错误或行为不一致。
• 依赖外部校验框架：如Hibernate Validator的@NotNull需配合JSR-380运行时校验，无法在构造时立即抛出异常。
• 忽略构造器控制权：record不允许显式定义无参构造函数或重载setter，开发者易陷入“无法干预初始化流程”的误区。

3. 解决方案演进路径

方案	实现方式	优点	缺点
自定义紧凑构造函数	使用this(...)委托并插入null检查	编译期保障，异常即时抛出	需手动编写每个校验逻辑
静态工厂方法封装	提供of()方法预处理参数	可复用、支持复杂校验规则	绕过record构造函数，需额外维护
结合Assert工具类	在紧凑构造函数中调用Objects.requireNonNull	代码简洁，标准库支持	错误信息定制性差

4. 核心实现：紧凑构造函数（Compact Constructor）

Java record允许定义紧凑构造函数，用于在隐式构造流程中插入校验逻辑。该构造函数不声明参数，仅对隐含参数执行前置检查。

public record UserDTO(String name, Integer age) {
    public UserDTO {
        if (name == null || name.isBlank()) {
            throw new IllegalArgumentException("Name must not be null or blank");
        }
        if (age == null || age < 0) {
            throw new IllegalArgumentException("Age must be non-negative");
        }
    }
}

上述代码在构造实例时即完成null及业务规则校验，确保对象状态合法，同时保留record的不可变特性。

5. 高阶模式：静态工厂 + 私有record

为增强封装性和校验灵活性，可将record设为私有，并通过公共静态工厂方法暴露创建接口。

public class UserDTOFactory {
    private record UserDTORecord(String name, int age) {}

    public static UserDTORecord of(String name, Integer age) {
        Objects.requireNonNull(name, "Name is required");
        if (name.trim().isEmpty()) 
            throw new IllegalArgumentException("Name cannot be empty");
        if (age == null || age < 0)
            throw new IllegalArgumentException("Valid age is required");
        
        return new UserDTORecord(name.trim(), age);
    }
}

此模式实现了关注点分离：工厂负责校验，record专注数据建模。

6. 与现代框架集成策略

在Spring Boot等框架中，常结合AOP或Controller Advice统一处理校验异常。但record的紧凑构造函数仍应在底层阻断非法状态。

1. 前端传参经Jackson反序列化时，可通过@JsonSetter(nulls = FAIL)配置拒绝null值。
2. Spring MVC中启用@Valid配合@NotNull注解，形成多层防御。
3. 在record构造函数中保留基础校验，防止绕过API层直接调用的情况。

7. 性能与可维护性权衡

尽管每次构造都执行校验会带来微量开销，但在大多数业务场景中可忽略不计。更重要的是避免后续因null值引发的连锁故障。

建议建立团队编码规范，统一采用“紧凑构造函数 + 标准化异常”模式，提升代码一致性。

8. 可视化流程：record null校验执行流

graph TD
    A[客户端传入参数] --> B{是否调用record构造函数?}
    B -- 是 --> C[进入紧凑构造函数]
    C --> D[执行null及业务校验]
    D -- 校验失败 --> E[抛出IllegalArgumentException]
    D -- 校验通过 --> F[完成对象初始化]
    B -- 否 --> G[调用静态工厂方法]
    G --> H[预校验参数合法性]
    H --> I{校验通过?}
    I -- 否 --> E
    I -- 是 --> J[委托创建record实例]
    J --> F

9. 扩展思考：未来语言层面的可能性

随着Java持续演进，社区已提出对record增强的支持，例如：

• 支持注解处理器在编译期生成校验代码
• 引入类似Kotlin的require内联约束语法
• 与Value Class提案结合，进一步优化内存与安全模型

当前虽需手动编码，但设计理念已趋近于“契约式设计”（Design by Contract）。

10. 实践建议与最佳实践清单

针对不同场景，推荐以下组合策略：

场景	推荐方案	工具/技术栈
简单DTO	紧凑构造函数 + Objects.requireNonNull	JDK原生
复杂业务规则	静态工厂方法	自定义异常类
API接口层	结合Spring Validation	@Valid, @NotNull
高性能要求	缓存校验结果或延迟校验	ThreadLocal标记
跨系统通信	Protobuf + 自定义parse逻辑	gRPC, Schema定义
审计敏感数据	构造时记录上下文信息	MDC, TraceID注入
泛型DTO	类型边界约束 + instanceof检查	Class<T>参数
可选字段	使用Optional包装	避免原始类型null
批量创建	流式校验 + 批量异常收集	Stream API, Collector
测试覆盖率	JUnit5 + 参数化测试	@ParameterizedTest