serialVersionUID的“long”默认值是Java序列化规范定义的默认值，由默认序列化行为计算得出。

因此，如果您添加了默认版本号，只要在结构上没有任何变化，您的类就会(反)序列化得更快，但是您必须注意，如果您更改了类(添加/删除字段)，那么您也会更新序列号。

如果你不需要兼容现有的比特流，你可以把1L放在那里，然后在有变化时根据需要增加版本。也就是说，当更改后的类的默认序列化版本与旧类的默认版本不同时。

Well, serialVersionUID is an exception to the rule that “static fields don’t get serialized”. ObjectOutputStream writes every time the value of serialVersionUID to the output stream. ObjectInputStream reads it back and if the value read from the stream does not agree with the serialVersionUID value in the current version of the class, then it throws the InvalidClassException. Moreover, if there is no serialVersionUID officially declared in the class to be serialized, compiler automatically adds it with a value generated based on the fields declared in the class.

据我所知，这只是为了与以前的版本兼容。只有当您之前忽略了使用serialVersionUID，然后进行了您知道应该是兼容的但导致序列化中断的更改时，这才有用。

有关更多细节，请参阅Java Serialization Spec。

序列化版本UID的目的是跟踪类的不同版本，以便执行有效的对象序列化。

其思想是生成一个对类的特定版本唯一的ID，然后在向类添加新细节(例如新字段)时更改该ID，这将影响序列化对象的结构。

总是使用相同的ID(例如1L)意味着在将来，如果类定义发生更改，导致序列化对象的结构发生更改，那么在尝试反序列化对象时很可能会出现问题。

如果省略了ID, Java将根据对象的字段实际为您计算ID，但我认为这是一个开销很大的过程，因此手动提供一个将提高性能。

下面是一些讨论类的序列化和版本控制的文章的链接:

JDC技术提示:2000年2月29日(链接在2013年2月中断) 了解Java Serialization API的秘密

为了补充@David Schmitts的回答，作为经验法则，我总是使用默认的1L。我只需要返回并更改其中一些数几次，但当我进行更改并每次更新默认数时，我知道这一点。

在我目前的公司，他们要求自动生成的号码，所以我使用它作为约定，但我更喜欢默认的。我的观点是，如果这不是您工作的约定，请使用默认值，除非您认为由于某种原因将不断更改序列化类的结构。

每次定义时，绝对应该创建一个serialVersionUID 实现java.io.Serializable的类。如果你不这样做，别人会的 自动为你创建，但这很糟糕。自动生成 serialVersionUID基于类的方法签名，因此 如果您在将来更改类以添加方法(例如)， 反序列化类的“旧”版本将失败。这就是 可能发生:

创建类的第一个版本，而不定义 serialVersionUID。 将类的实例序列化到持久存储中;一个 serialVersionUID为您自动生成。 修改类以添加新方法，并重新部署应用程序。 尝试反序列化在第2步中序列化的实例，但现在它失败了(当它应该成功时)，因为它有 不同的自动生成serialVersionUID。