Java record 序列化和普通类有什么不同

Java record 实现 Serializable 后，确实可以像普通类一样交给 ObjectOutputStream 写入，但两者不是同一套对象重建契约：record 的序列化状态由组件决定，反序列化会调用它的规范构造器；普通可序列化类则按普通对象序列化机制重建，并可以使用一组自定义钩子。这个差异会直接影响校验逻辑、旧数据兼容和是否适合把类型当作长期存储格式。

Java record 和普通类的序列化契约先看这张表

这里的“record 更简单”不是说它更适合所有持久化场景。它把状态和构造入口收紧，换来的是更容易理解的值载体；代价是你不能再把大量兼容逻辑藏在私有序列化钩子里。

用最小代码看两种对象如何写入

先定义一个 record 和一个普通类。示例把密码、Token 等敏感字段排除在外，只演示稳定的订单摘要：

import java.io.Serializable;
import java.math.BigDecimal;

// record 的组件是公开的数据契约，组件类型也必须可序列化。
record OrderSummary(String orderId, BigDecimal amount) implements Serializable {
    // 规范构造器可集中做不变量校验。
    OrderSummary {
        if (orderId == null || orderId.isBlank()) {
            throw new IllegalArgumentException("orderId is blank");
        }
        if (amount == null || amount.signum() 

两种对象都能写入流，但它们表达状态的方式不同：record 的组件名、顺序和类型组成 record descriptor；普通类则需要同时考虑字段、版本号以及是否存在自定义读写逻辑。若 BigDecimal 或其他组件类型不满足可序列化要求，写入阶段仍会失败，record 不会替你把组件转换成字符串。

反序列化时，record 会走规范构造器

这是最容易被忽略的行为。普通类的 Java 原生反序列化并不是简单调用业务构造器；而 serializable record 会把流中的组件值交给 canonical constructor，再生成 record 对象。因此上例里的空订单号和负金额校验，在 record 被反序列化时仍是构造边界的一部分。

调用代码可以保持普通的流操作，但验收要把构造失败当成协议错误处理，而不是把它当成网络重试：

static  T roundTrip(T value) throws Exception {
    // 先写入内存流，避免示例依赖磁盘文件。
    var output = new java.io.ByteArrayOutputStream();
    try (var objectOut = new java.io.ObjectOutputStream(output)) {
        objectOut.writeObject(value);
    }

    // 读取时 record 的组件值会进入规范构造器。
    try (var objectIn = new java.io.ObjectInputStream(
            new java.io.ByteArrayInputStream(output.toByteArray()))) {
        @SuppressWarnings("unchecked")
        T restored = (T) objectIn.readObject();
        return restored;
    }
}

在实际服务中，建议至少覆盖三类结果：正常对象可以往返；组件里出现不可序列化成员时明确失败；流里的值无法满足规范构造器约束时记录协议版本和字段来源。不要只断言对象“能读回来”，还要断言不变量没有被绕开。

自定义序列化时，record 的边界更硬

普通类可以按 Java 序列化规范提供 writeObject、readObject、readObjectNoData 或外部化方法，把旧字段映射到新字段、过滤不再保存的状态，或者在读取后补齐默认值。record 的设计目标是让组件状态保持透明一致，所以这些方法不能像普通类那样改变 record 的序列化和反序列化过程，会被忽略。

因此选型可以按调用方需求来定：

• 只需要传递一组稳定值，且希望读取时统一执行构造校验：优先考虑 record。
• 需要隐藏字段、兼容多代旧流、替换字段表示，或已经依赖自定义钩子：保留普通类。
• 要跨语言、跨服务或长期归档：不要把 Java 原生序列化当成公共协议，改用明确版本和字段规则的外部格式。

一个实用的回归清单是：组件类型是否可序列化；规范构造器是否能接收历史数据；字段改名是否有迁移策略；反序列化失败是否能区分坏数据和临时网络错误。

常见问题

record 只要实现 Serializable 就一定能序列化吗？

不一定。每个参与写入的组件值仍要满足 Java 序列化要求；某个成员不可序列化时，写入会抛出异常。record 解决的是对象状态和重建入口的表达问题，不会自动转换成员类型。

record 的规范构造器能校验反序列化数据吗？

能。serializable record 反序列化时会调用规范构造器，因此构造器中的非空、范围和格式约束仍然是对象成立的条件。

什么时候不能用 record 做旧数据兼容？

当旧数据需要复杂字段映射、删除敏感字段、按版本补默认值，或必须依靠 readObject 控制恢复过程时，普通类或先做版本归一化的 DTO 更合适。

把 record 看成“带强构造边界的值载体”，把普通类看成“可扩展的对象协议”，两者的差异就清楚了：前者让组件状态和规范构造器保持一致，后者给兼容策略留下更多插入口。决定类型之前，先问清楚数据是短生命周期的内部值，还是要承受多年版本演进的存储协议。