长话短说，此字段用于检查序列化数据是否可以正确反序列化。序列化和反序列化通常由程序的不同副本进行，例如服务器将对象转换为字符串，客户端将接收到的字符串转换为对象。此字段告诉两者对该对象的概念相同。此字段在以下情况下有帮助：

你在不同的地方有很多不同的程序副本（比如1个服务器和100个客户端）。如果您将更改对象、更改版本号并忘记更新此客户端，它将知道他无法反序列化您已将数据存储在某个文件中，稍后您尝试使用带有修改对象的程序的更新版本打开它-如果您保持正确的版本，您将知道此文件不兼容

什么时候重要？

最明显的是，如果向对象中添加一些字段，旧版本将无法使用它们，因为它们的对象结构中没有这些字段。

不太明显——反序列化对象时，字符串中不存在的字段将保持为NULL。如果您已经从对象中删除了字段，则旧版本会将此字段始终保持为NULL，如果旧版本依赖此字段中的数据，则会导致错误行为（无论如何，您创建它是为了某种目的，而不仅仅是为了好玩：-））

最不明显的-有时你改变了你在某个领域的含义。例如，当你12岁时，你的意思是“自行车”下的“自行车”，但当你18岁时，意思是“摩托车”-如果你的朋友邀请你“骑自行车穿越城市”，而你将是唯一一个骑自行车来的人，你将不明白在不同领域保持相同的含义是多么重要：-）

例如，缺少serialVersionUID可能会导致问题：

我正在研究这个JavaEE应用程序，它由一个使用EJB模块的Web模块组成。web模块远程调用EJB模块，并传递实现Serializable的POJO作为参数。

这个POJO的类被打包在EJB jar中，并被打包在WEB模块的WEB-INF/lib中它自己的jar中。它们实际上是同一个类，但当我打包EJB模块时，我打开了这个POJO的jar，将其与EJB模块打包在一起。

对EJB的调用失败，出现以下异常，因为我没有声明其serialVersionUID：

Caused by: java.io.IOException: Mismatched serialization UIDs : Source
 (Rep.
 IDRMI:com.hordine.pedra.softbudget.domain.Budget:5CF7CE11E6810A36:04A3FEBED5DA4588)
 = 04A3FEBED5DA4588 whereas Target (Rep. ID RMI:com.hordine.pedra.softbudget.domain.Budget:7AF5ED7A7CFDFF31:6227F23FA74A9A52)
 = 6227F23FA74A9A52

长话短说，此字段用于检查序列化数据是否可以正确反序列化。序列化和反序列化通常由程序的不同副本进行，例如服务器将对象转换为字符串，客户端将接收到的字符串转换为对象。此字段告诉两者对该对象的概念相同。此字段在以下情况下有帮助：

你在不同的地方有很多不同的程序副本（比如1个服务器和100个客户端）。如果您将更改对象、更改版本号并忘记更新此客户端，它将知道他无法反序列化您已将数据存储在某个文件中，稍后您尝试使用带有修改对象的程序的更新版本打开它-如果您保持正确的版本，您将知道此文件不兼容

什么时候重要？

最明显的是，如果向对象中添加一些字段，旧版本将无法使用它们，因为它们的对象结构中没有这些字段。

不太明显——反序列化对象时，字符串中不存在的字段将保持为NULL。如果您已经从对象中删除了字段，则旧版本会将此字段始终保持为NULL，如果旧版本依赖此字段中的数据，则会导致错误行为（无论如何，您创建它是为了某种目的，而不仅仅是为了好玩：-））

最不明显的-有时你改变了你在某个领域的含义。例如，当你12岁时，你的意思是“自行车”下的“自行车”，但当你18岁时，意思是“摩托车”-如果你的朋友邀请你“骑自行车穿越城市”，而你将是唯一一个骑自行车来的人，你将不明白在不同领域保持相同的含义是多么重要：-）

简单解释：

您正在序列化数据吗？序列化基本上是将类数据写入文件/流等。反序列化是将数据读回类。你打算投入生产吗？如果您只是用不重要的/假的数据测试一些东西，那么不要担心它（除非您是直接测试序列化）。这是第一个版本吗？如果是，请将serialVersionUID设置为1L。这是第二、第三等prod版本吗？现在您需要担心serialVersionUID，并且应该深入研究它。

基本上，如果在更新需要写入/读取的类时没有正确更新版本，那么在尝试读取旧数据时会出现错误。

我不能错过这个机会，插上乔什·布洛克（Josh Bloch）的书《有效的Java》（第二版）。第10章是关于Java序列化的不可或缺的资源。

根据Josh的说法，自动生成的UID是基于类名、实现的接口以及所有公共和受保护的成员生成的。以任何方式更改任何这些都将更改serialVersionUID。因此，只有当您确定不会有多个版本的类被串行化（跨进程或稍后从存储中检索）时，才不需要使用它们。

如果您现在忽略它们，然后发现需要以某种方式更改类，但保持与旧版本类的兼容性，则可以使用JDK工具serialver在旧类上生成serialVersionUID，并在新类上显式设置。（根据您的更改，您可能还需要通过添加writeObject和readObject方法来实现自定义序列化-请参阅Serializable javadoc或上述第10章。）

这个问题在Joshua Bloch的《有效Java》中有很好的记录。一本非常好的书，是一本必读的书。我将概述以下原因：

序列化运行时为每个可序列化类提供一个名为Serialversion的数字。此编号称为serialVersionUID。现在这个数字背后有一些数学，它是基于类中定义的字段/方法得出的。对于同一类，每次都会生成相同的版本。在反序列化过程中使用此数字来验证序列化对象的发送方和接收方是否已为该对象加载了与序列化兼容的类。如果接收方为对象加载的类具有与对应发送方类不同的serialVersionUID，则反序列化将导致InvalidClassException。

如果类是可序列化的，则还可以通过声明名为“serialVersionUID”的字段来显式声明自己的serialVersionUID，该字段必须是静态的、final的和long类型的。大多数IDE（如Eclipse）都可以帮助您生成长字符串。