字节流序列化不适用于超大或异构对象深拷贝：超大对象引发oom与gc停顿，异构场景因类签名不一致导致invalidclassexception、classnotfoundexception等错误。
字节流序列化方式本身不适用于超大对象的异构深拷贝——它既不是为“超大”设计，也不支持“异构”场景。
超大对象会触发严重性能与内存问题
序列化整个对象图需一次性加载全部数据到内存：ByteArrayOutputStream 内部用数组扩容，对象越大，临时字节数组越庞大；反序列化时 ObjectInputStream 还要递归重建所有嵌套实例。实测中，单个 50MB+ 的 POJO 就可能引发 OutOfMemoryError 或 GC 长停顿。JDK 原生序列化没有分块、流式或增量处理能力，无法拆解或缓冲。
- 100MB 对象 ≈ 生成 100MB+ 字节数组（含元数据膨胀）
- GC 压力陡增，尤其在老年代空间不足时直接 Full GC
- 无超时控制、无进度反馈，失败后难以定位是哪一层引用导致卡死
异构意味着序列化机制根本不可用
“异构”指源对象与目标环境存在类结构差异，例如：字段增删、类型变更、包名不同、JDK 版本跨代（如 JDK 8 → JDK 17）、或使用了不同框架生成的代理类。而 Java 原生序列化强依赖 serialVersionUID 和类签名一致性：
- 新增非 transient 字段 → 反序列化抛 InvalidClassException
- 字段从 String 改为 CharSequence → ClassCastException 或 null 值静默丢失
- 源端是 Spring CGLIB 代理，目标端无对应 Enhancer 类 → NotSerializableException
- 使用了 record（JDK 14+）但目标运行时是 JDK 11 → ClassNotFoundException
真正可行的替代路径
面对超大 + 异构需求，应放弃“全量字节流序列化”思路，转向分层、契约驱动、可中断的拷贝策略：
- 按业务语义切片：把超大对象拆成逻辑子单元（如订单主表 + 子项列表 + 日志集合），各自独立序列化/传输/重建
- 用中间格式做桥接：转为 JSON（Jackson / Gson）或 Protobuf（.proto 定义 schema），天然支持字段映射、缺失容忍、版本兼容
- 手动构造 + 差异合并：定义 DTO 接口，通过 Builder 模式逐字段赋值；对异构字段加 @JsonAlias、@ProtoField(default = "...") 显式声明降级策略
- 资源型字段单独处理：文件句柄、数据库连接、线程等不可序列化内容，改用 URI/ID 引用 + 运行时重绑定
字节流序列化只适合结构稳定、体积可控、纯内存内流转的小型 POJO 深拷贝。超大和异构，是它的明确禁区。
