ObjectInputStream只能读取由ObjectOutputStream序列化生成的文件，否则抛StreamCorruptedException；需确保类实现Serializable、serialVersionUID一致，并用try-with-resources捕获IO、ClassNotFoundException和InvalidClassException。
ObjectInputStream 读取文件前必须确认对象已序列化
直接用 ObjectInputStream 读一个普通文件会抛 java.io.StreamCorruptedException: invalid stream header。这是因为 ObjectInputStream 只能解析由 ObjectOutputStream 写出的二进制流——它依赖特定魔数（AC ED 00 05）校验头信息。如果文件是文本、JSON 或其他格式，根本不是序列化流，强行读就会失败。
实操建议：
- 确保该文件是由
ObjectOutputStream调用writeObject()写入的，且写入后调用了close()或flush() - 检查类定义是否实现了
Serializable，且未修改serialVersionUID（否则会报InvalidClassException） - 若用 IDE 生成
serialVersionUID，请统一使用private static final long serialVersionUID = 1L;这类固定值，避免因 IDE 自动生成差异导致反序列化失败
正确构造 ObjectInputStream 并处理常见异常
不能裸写 new ObjectInputStream(new FileInputStream("data.bin"))，必须包裹在 try-with-resources 中，并显式捕获三类关键异常：IO 异常、类找不到异常、序列化版本不匹配异常。
示例片段：
立即学习“Java免费学习笔记（深入）”；
try (FileInputStream fis = new FileInputStream("data.bin");
ObjectInputStream ois = new ObjectInputStream(fis)) {
MyData obj = (MyData) ois.readObject();
} catch (IOException e) {
// 文件不存在、权限不足、流损坏等
} catch (ClassNotFoundException e) {
// 反序列化时类不在 classpath 中（比如换了 jar 包或删了类）
} catch (InvalidClassException e) {
// serialVersionUID 不一致，或类结构发生不兼容变更（如删字段、改类型）
}
注意：readObject() 返回的是 Object，必须强制转型，转型失败会抛 ClassCastException——这通常说明写入和读取用的不是同一个类（包名/版本不同）。
反序列化时的类路径与兼容性陷阱
哪怕文件能打开、头校验通过，也可能在 readObject() 时卡住或崩溃，原因往往藏在类定义里：
- 类中存在未实现
Serializable的成员（如Thread、Socket），且没被transient修饰 → 抛NotSerializableException - 父类没实现
Serializable，子类也未提供无参构造器 → 反序列化时无法重建父类状态，可能静默丢数据或抛异常 - 使用了 Lambda 或匿名内部类 → 它们默认带隐式引用，容易引发
ClassNotFoundException或意外序列化外部对象 - JDK 版本跨度过大（如用 JDK 17 序列化，JDK 8 读取）→ 部分内置类序列化格式不兼容，建议限定在同一 JDK 大版本内操作
替代方案比硬扛 ObjectInputStream 更可靠
除非你完全控制两端（写入方和读取方）、且对象结构长期稳定，否则不推荐在持久化场景中依赖 Java 原生序列化。它的耦合太强，升级风险高。
更务实的选择：
- 换成 JSON：用
ObjectMapper.readValue(new File("data.json"), MyData.class)（Jackson），可读性强、跨语言、容错率高 - 换成 Protocol Buffers 或 Avro：适合高性能、多语言、schema 演进需求强的场景
- 若必须用二进制，至少加一层封装：把
ObjectOutputStream输出的字节先 Base64 编码存为文本，避免传输/编辑时被破坏
真正难的不是怎么调 readObject()，而是保证写入那一刻起，类定义、JDK、类加载器、依赖链全部没变过——这点在真实项目里几乎不可控。
