Java记录类实现值对象

如果一个对象没有独立身份，两个实例只要字段值相同就应该相等，那么它更像“值”而不是“实体”。Java 的 record 正好适合承载这类对象：声明组件后，编译器会提供访问器、规范构造器、equals、hashCode 和 toString。把校验和规范化逻辑放进构造器，就能得到一个短小但有边界的值对象。

官方参考：https://docs.oracle.com/en/java/javase/26/language/records.html

下面用金额值对象说明完整做法。示例以 Java 16 及以后已经成为正式语言特性的 record 为前提，重点不是省几行代码，而是让“按值相等”和“不变量”成为类型的一部分。

先判断：这个对象是不是只有值

值对象通常没有数据库主键意义上的身份，也不需要通过一串变化来追踪生命周期。例如货币金额、坐标、日期范围、邮箱地址，比较时关心的是它们携带的值。相反，订单、账户、设备这类对象即使字段暂时相同，也可能代表两个不同实例，不能只因为 record 写法简洁就替换。

因此采用 record 前先问三个问题：相等是否由全部组件决定？对象创建后是否不应再改变？是否不需要继承一个具体父类？三个答案基本都为“是”，才进入下一步。

用 record 获得值对象的基础语义

最小声明可以只有一行：

// 两个组件共同决定 Money 的值身份
public record Money(String currency, BigDecimal amount) {
}

它会生成 currency() 和 amount() 访问器，而不是传统 JavaBean 风格的 getCurrency()；组件字段是私有 final，record 本身隐式 final。两个 Money 实例的 equals 和 hashCode 会按同类型的组件值判断，这正是值对象放进集合或作为 Map 键时需要的语义。

record 仍然可以实现接口，也可以添加业务方法，但不能显式继承另一个类。需要共享行为时，把行为抽成接口通常比强行保留父类更合适。

把校验和规范化放进紧凑构造器

值对象最容易出问题的地方不是声明，而是非法状态。可以使用紧凑构造器校验参数；在构造器体中重新给参数赋值，规范化后的值会被写入隐式字段。

import java.math.BigDecimal;
import java.math.RoundingMode;
import java.util.Locale;
import java.util.Objects;

// Money 只允许非空货币代码和非负金额，并统一金额精度
public record Money(String currency, BigDecimal amount) {
    public Money {
        // 先拒绝空引用，避免后续调用出现含义不清的异常
        Objects.requireNonNull(currency, "currency");
        Objects.requireNonNull(amount, "amount");
        // 规范化货币代码，让等价输入得到同一表示
        currency = currency.strip().toUpperCase(Locale.ROOT);
        if (currency.length() != 3) {
            throw new IllegalArgumentException("货币代码必须是 3 个字符");
        }
        if (amount.signum() 

这样创建 new Money(" cny ", new BigDecimal("12.3")) 后，组件值会被统一为 CNY 和 12.30。非法输入在对象离开构造器前就被拒绝，调用方不必在每个入口重复写规则。

四个边界决定能不能放心落地

第一，record 是浅层不可变。组件引用不能重新指向别的对象，但如果组件本身是可变集合，外部仍可能修改其内容。集合组件应在紧凑构造器里使用 List.copyOf 或其他不可变副本。

import java.util.List;

// 复制集合，避免调用方持有的可变 List 改变 record 的观察结果
public record Tags(List values) {
    public Tags {
        // List.copyOf 同时拒绝 null 元素并返回不可变列表
        values = List.copyOf(values);
    }
}

第二，组件必须代表完整的相等规则。如果金额还要区分来源、时间或租户，就应把这些因素列入组件；否则自动生成的 equals 会给出过于宽松的结果。

第三，record 不适合有身份的实体。需要无参构造、懒加载、代理、可变生命周期或继承层次时，普通 class 往往更稳妥。迁移时应先确认序列化和框架支持，再替换 API 类型。

第四，规范化规则要稳定。把舍入、大小写、空白处理等规则放进构造器后，修改它可能改变持久化数据、缓存键或接口契约，应该当作领域规则来评审。

常见问题

record 能不能实现接口？

可以。record 不能继承普通类，但可以实现一个或多个接口，并补充接口要求的方法。

record 能不能直接当 JPA 实体？

不要默认可以。实体通常需要身份、生命周期、代理或框架约定；record 更适合 DTO、查询结果和领域值对象。是否支持取决于具体框架和版本，不能只看 Java 语言层面的语法。

总结一下：先用“相等是否只看值”筛选对象，再用 record 表达组件，最后在紧凑构造器里固定不变量。只要记住它是浅层不可变的数据载体，而不是万能实体基类，Java 记录类就能把值对象的意图直接写进类型定义。