确保要被序列化的类定义并分配一个值给static final long serialVersionUID，你就没有问题了。

话虽如此，通常我不会这样做。我的首选是仅在单个进程内使用正常序列化，或在两个进程之间使用同一机器上的序列化类从同一个jar文件获取。如果不是这种情况，将序列化为XML是更好、更安全的选择。

随着serialVersionUID ，包结构在序列化时必须保持一致，因此如果您在1.4中有myjar.mypackage.myclass ，则必须在1.6中保持myjar.mypackage.myclass 。

在包结构中包含Java版本或发布版本并不罕见。即使serialVersionUID在编译之间保持不变，包结构仍会导致不兼容的版本异常在运行时抛出。

顺便提一下，如果在您的类中实现Serializable，如果缺少serialVersionUID，您应该会收到编译器警告。

以我的观点（基于相当痛苦的多年经验），Java本地序列化存在许多问题，如果可能的话应该避免使用，尤其是因为有出色的XML / JSON支持。如果必须进行本地序列化，则建议将类隐藏在接口后面，并在后台实现工厂模式，当需要时创建正确类的对象。

您还可以使用此抽象来检测不兼容版本异常，并在幕后执行必要的转换，以迁移对象中的数据。

Java库类应该在1.4和1.6之间具有兼容的序列化形式，除非另有说明。Swing明确声明版本不兼容，因此如果您尝试序列化Swing对象，则会遇到问题。

您可能会遇到某些问题，其中javac生成的代码略有不同。这将更改serialVersionUID 。您应确保在所有可序列化的类中明确声明UID。

不，不同版本的JVM不会破坏序列化本身。

如果您正在序列化的一些对象来自Java运行时，并且它们的类发生了不兼容的演变，您将看到失败。大多数核心Java类对此非常小心，但在过去的某些软件包中出现过不连续。

多年来，我已成功地在RMI的上下文中使用序列化与来自不同编译的类，在运行不同版本的Java运行时的不同机器上。

我不想偏离原问题太远，但我想指出，无论格式如何，演变序列化类总是需要注意的。这不是Java序列化特有的问题。无论你序列化为XML、JSON、ASN.1等，你都必须处理相同的概念。Java序列化对允许的内容及如何进行允许的更改有相当明确的规定。有时这是限制性的，有时有处方是有帮助的。

如果双方使用相同的jar文件，则大多数情况下都可以正常工作。但是，如果您使用同一软件包/模块/框架的不同版本（例如不同的weblogic jars或某些“罕见”异常的扩展使用），则需要进行大量集成测试，然后才能获得批准。