serialVersionUID 一样，旧对象也未必能按新规则恢复

升级以后，旧文件能够readObject，新增字段却是null；把一个int改成long，两版都写着相同serialVersionUID，又在读取时失败。这两个结果看起来相反，实际上在提醒同一件事：UID不是一次“所有改动都兼容”的签字。

原生序列化有字段匹配和对象恢复规则。能否读出字节、读出的值是什么、这些值是否符合新版本业务，各自需要证据。下面不靠两份项目手工切换，直接用JDK编译器构造三个同名类版本，让同一份旧字节进入不同接收类。

三个版本都叫fixture.State，UID都为1。v1持有int quantity=7；v2保留它并新增note，源码初始化为new-default；v3把quantity改成long。程序让它们进入不同类加载器，避免同一运行环境里类名冲突。

先观察两条升级结果

完成实验以后会看到：v2中的quantity为7，note却是null；v3因InvalidClassException失败。新增字段不在旧流中，按恢复规则取得默认值，不会因为新源码写了字段初始化器就自动填入new-default。类型改动则触及不兼容字段布局，同样UID也不能绕过。

这里的int到long尤其容易误判。在普通Java表达式里，int可以拓宽成long；默认序列化的字段匹配却不负责替所有历史字段执行这种类型转换。语言赋值规则不能直接当作持久格式迁移规则。

一份文件完成三个版本实验

需要完整JDK 17，不能只装没有JavaCompiler的精简运行时。保存为 SerialEvolution.java，执行 java SerialEvolution.java。程序把源码和类文件放在自己创建的临时目录，结束后清理，不覆盖当前项目。

import java.io.*;
import java.net.*;
import java.nio.file.*;
import java.util.Comparator;
import java.util.stream.Stream;
import javax.tools.*;
public class SerialEvolution {
    static Class<?> compile(Path root, String fields) throws Exception {
        Path src = root.resolve("fixture/State.java"); Files.createDirectories(src.getParent());
        String code = "package fixture; public class State implements java.io.Serializable {"
                + "private static final long serialVersionUID=1L;" + fields + "public State(){} }";
        Files.writeString(src, code);
        JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
        if (compiler == null) throw new IllegalStateException("full JDK required");
        if (compiler.run(null, null, null, "--release", "17", "-d", root.toString(), src.toString()) != 0)
            throw new IllegalStateException("compilation failed");
        return Class.forName("fixture.State", true,
                new URLClassLoader(new URL[]{root.toUri().toURL()}, ClassLoader.getPlatformClassLoader()));
    }
    static byte[] write(Object value) throws IOException {
        ByteArrayOutputStream bytes = new ByteArrayOutputStream();
        try (ObjectOutputStream out = new ObjectOutputStream(bytes)) { out.writeObject(value); }
        return bytes.toByteArray();
    }
    static Object read(byte[] bytes, Class<?> target) throws Exception {
        try (ObjectInputStream in = new ObjectInputStream(new ByteArrayInputStream(bytes)) {
            protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {
                return desc.getName().equals("fixture.State") ? target : super.resolveClass(desc);
            }
        }) { return in.readObject(); }
    }
    public static void main(String[] args) throws Exception {
        Path root = Files.createTempDirectory("serial-evolution-");
        Class<?> one = null, two = null, three = null;
        try {
            one = compile(root.resolve("v1"), "public int quantity=7;");
            two = compile(root.resolve("v2"), "public int quantity=7; public String note=\"new-default\";");
            three = compile(root.resolve("v3"), "public long quantity=7L;");
            byte[] old = write(one.getConstructor().newInstance());
            Object restored = read(old, two);
            System.out.println("quantity=" + two.getField("quantity").get(restored));
            System.out.println("new_note=" + two.getField("note").get(restored));
            try { read(old, three); throw new AssertionError(); }
            catch (InvalidClassException expected) { System.out.println("int_to_long=INCOMPATIBLE"); }
        } finally {
            for (Class<?> type : new Class<?>[]{one, two, three}) {
                if (type != null) ((URLClassLoader)type.getClassLoader()).close();
            }
            try (Stream<Path> paths = Files.walk(root)) {
                for (Path path : paths.sorted(Comparator.reverseOrder()).toList()) Files.deleteIfExists(path);
            }
        }
    }
}

输出：

quantity=7
new_note=null
int_to_long=INCOMPATIBLE

编译器每次输出到独立目录，类加载器分别读取对应版本。自定义resolveClass只在本实验中把fixture.State定位到指定接收类，不是生产系统应当接受任意类名的示范。生产反序列化还需要单独限制输入来源、允许类型与对象图规模。

note 的源码默认值为什么没出现

对普通可序列化类，默认恢复不等于执行一次它的普通构造器，再把旧字段随便覆盖。字段初始化器不能被当成缺失持久字段的迁移逻辑。新版本看到的null，不代表序列化框架忘了读文件，而是旧流根本没有这项字段。

如果新业务规定note非空，升级以后立刻调用note.length就可能失败；如果把null当成“无需审核”，则可能更糟：读取成功却改变了业务判断。兼容测试必须继续运行关键业务操作，不能以readObject未抛异常作为唯一成功条件。

新增基本类型字段也有类似问题，例如计数默认为0、标记默认为false。它们恰好是合法值时，历史记录是否应该被解释为该状态，需要产品或领域规则决定。默认值可以让结构恢复继续进行，不负责替旧数据补上本来不存在的信息。

删除字段与改语义，同样值得单独回归

删除字段可能让旧流中的相关数据不再进入新对象；即使读取不报错，历史信息已经被丢弃。若后续又想把这份新对象写回，不能假定删掉的信息会自动在另一轮写入中保留。

字段名字没改、类型没改，也可能发生更隐蔽的不兼容。例如quantity从“件数”改成“最小包装单位数”，或者时间从秒改成毫秒，默认机制没有办法识别这层语义。相同UID和成功读取都不会报警，只有跨版本业务断言才能暴露。

父类变化、transient调整、定制writeObject/readObject和Externalizable等都有自己的规则。本例刻意使用普通默认序列化，只证明选定的三种结构。不要把它扩大成所有Serializable类型演进的完整矩阵。

需要迁移时，把旧状态当旧状态处理

对于仍需长期保留的序列化数据，可以显式记录格式版本，在受控读取路径里把旧模型转换成当前模型，并验证所有新不变量。转换后的数据再写入新的存储格式，保留可回退的原始样本。这样变更逻辑能被命名和测试，而不是躲在一串默认字段值里。

定制readObject可以参与恢复，但必须理解它的签名与调用契约，先默认读取再检查或迁移，并对非法状态抛出明确错误。它不是让不可信对象图变安全的补丁，也不应该在恢复时顺手发网络请求或修改外部系统。

如果新字段的合理缺省无法从旧数据推断，就需要拒绝或交给显式修复流程。把一个任意值写进去让程序继续跑，只是把兼容错误推迟到业务结果中。迁移最难的部分常常不是字节能否读取，而是旧记录没有保存新规则需要的信息。

UID 的作用不要被神化，也不要省略

显式UID有助于让类演进意图可见，避免默认计算受类细节变化影响；它仍然有用途。但固定UID以后，维护者就需要承担逐项核对兼容性的责任，不能把它当免测开关。反过来，随便改UID会让旧数据整体拒绝，也可能破坏滚动升级期间不同实例的通信。

升级前应保留来自真实旧版本的脱敏字节样本，覆盖最小对象、缺省字段、边界值、对象共享与已知历史版本。用新版本读取后，断言字段和业务动作；若需要双向兼容，还应让旧版本读取新版本写出的数据。一个只使用当前类往返的测试，不可能证明跨版本兼容。

对永久文件、缓存和消息还要分别判断。可重建缓存也许可以换命名空间整体重建，长期数据则必须有迁移和回退；滚动消息链路还要考虑同一时间并存的版本。三个场景不能因为都实现Serializable，就共享一条草率的升级策略。

这份实验没有保存任何外部数据，输出的null与类型拒绝已经足以限定结论：相同UID并不负责默认值迁移，也不负责字段类型转换。真正需要保留下来的，是能够跨版本重复执行的样本和对应业务判断。

缺少一个字段，与字段原来就是 null 怎么区分

默认读取以后，两种情况都可能表现为null：旧版本根本没有note，或者某个已有note的版本明确保存了null。若迁移需要对两者作不同处理，单看对象当前值已经不够。ObjectInputStream的GetField提供defaulted判断，可以在定制读取时识别某个字段是否出现在流中，再按已约定版本规则选择缺省。

这仍不意味着“缺失就填new-default”永远正确。缺省可能要从旧字段推导，也可能要求人工确认；若既有版本允许null，它又可能是一种有意义的状态。迁移代码应保留这些区别，而不是把所有null统一修成同一个字符串。

本文没有把这段迁移塞入实验类，正是为了让默认行为先暴露出来。扩展实验时，可以另建v4，用同一份旧字节核对缺失路径，再让v2主动写出null核对显式空值路径。成功条件应分别写出，不仅验证最后“总能读出一个非空值”。

若类通过serialPersistentFields定制持久字段，源码字段与流字段还可能不再一一对应。那时需要围绕实际持久契约维护测试，不能从反射看见几个成员变量就推断文件中保存了什么。