Java record在紧凑构造器中校验组件的实现方法

Java record 的紧凑构造器适合放置“对象一出生就必须成立”的约束：例如用户名不能为空、邮箱要先去掉首尾空格、数量不能小于 1。它本质上仍是 record 的规范构造器，只是省略了参数列表和字段赋值；构造器主体结束后，编译器会把参数写入对应的私有最终字段。

校验直接写在 public User 紧凑构造器里，简单归一化可以重赋值给同名参数；不要在其中手动写 this.field = field。如果组件是 List 等可变对象，再用 List.copyOf 切断外部集合的修改影响。

先把不可变约束放进规范构造路径

record 的组件会生成访问器、equals、hashCode 和规范构造器。若只在业务服务里校验，另一个调用入口仍可能创建出空用户名或负数量的对象。把“对象必须满足的约束”放进构造路径，调用方拿到实例时就可以默认这些条件已经成立。

这里的边界是数据不变量，不是完整业务流程。例如“邮箱不能为空”适合放进 record；“这个邮箱今天是否已经注册”依赖数据库，不应该塞进值对象的构造器。

紧凑构造器如何同时完成校验和归一化

紧凑构造器不重复写组件参数，因此特别适合“检查几个字段，再做很小的标准化”。下面的 Account 拒绝空用户名和非法邮箱，同时把输入两端空格去掉。给参数重新赋值后，构造器末尾的隐式赋值会使用新值。

public record Account(String username, String email) {
    public Account {
        // 先归一化文本，避免校验通过后仍保存无意义的首尾空格。
        username = username == null ? null : username.trim();
        email = email == null ? null : email.trim().toLowerCase(java.util.Locale.ROOT);

        // record 的不变量在对象落地前检查，失败就不创建实例。
        if (username == null || username.isEmpty()) {
            throw new IllegalArgumentException("username must not be blank");
        }
        if (email == null || !email.contains("@")) {
            throw new IllegalArgumentException("email is invalid");
        }
        // 这里不要写 this.username = username；字段赋值由紧凑构造器隐式完成。
    }
}

校验顺序也有意义：先处理允许的格式归一化，再判断归一化后的值是否满足约束。不要把数据库查询、远程调用或复杂副作用放进这里，否则一个看似简单的值对象会变成难以测试的服务入口。

三种构造方式怎么选

紧凑构造器并不是所有场景的唯一答案。需要显式改变每个字段的赋值方式时，应该写完整的规范构造器；需要从不同形态的输入创建 record 时，则增加重载构造器，并让它调用规范构造器。

public record OrderLine(String sku, int quantity, java.util.List labels) {
    public OrderLine {
        // 防御性复制让调用方后续修改原集合时不影响 record 状态。
        labels = labels == null ? java.util.List.of() : java.util.List.copyOf(labels);
        if (sku == null || sku.isBlank()) {
            throw new IllegalArgumentException("sku must not be blank");
        }
        if (quantity 

List.copyOf 返回的是不可变副本，并且会拒绝集合中的 null 元素；这类行为属于组件边界的一部分，团队应在 API 文档或测试中明确。若组件本身是可变对象，record 的字段是 final 并不等于对象图完全不可变。

编译器赋值顺序决定了哪些写法成立

紧凑构造器的参数是由 record 组件隐式声明的，因此可以直接使用 username、email 这些名字，也可以给它们重新赋值。构造器主体中不能显式给对应字段赋值，因为这些字段在语义上仍由构造器末尾的隐式步骤初始化。

如果写成完整的规范构造器，就必须自己重复参数列表并完成每个字段的赋值：

public record Point(int x, int y) {
    public Point(int x, int y) {
        // 完整规范构造器需要显式维护两个组件到字段的映射。
        if (x 

两种形式表达的是同一条规范构造路径。完整形式的优点是赋值和转换过程完全可见，代价是组件增删时更容易漏改参数或字段；紧凑形式更适合单纯校验、归一化和防御性复制。

用一张表检查校验责任是否清晰

常见问题

紧凑构造器里能不能写 this.field = field？

不能把它当成普通构造器使用。紧凑构造器的字段赋值由编译器在主体结束后补上；需要显式控制赋值时改写为完整规范构造器。

给紧凑构造器参数重新赋值会改变 record 字段吗？

会。参数重赋值会影响构造器末尾的隐式赋值，因此适合做 trim、大小写标准化和防御性复制，但应保持逻辑简单。

record 做了校验就等于业务数据一定合法吗？

不等于。record 适合保证局部、稳定、无需外部状态的不变量；权限、库存、唯一性和跨表规则仍应由应用服务或数据库约束负责。