这个问题与以下内容完全相同：
讽刺的是，Michael Bogswardt也回答说。
Michael Bogswardt生成serialVersionUID的答案让我思考。有没有理由生成像eclipse和IDEA（或简单的serialver）这样的正确的serialVersionUID？或者插入1L一样好吗？
答案 0 :(得分：11)
一旦你在那里写了一个数字（任意数字），当你对类进行兼容性破坏的更改时，你有责任碰撞它（例如，更改JavaDoc不会破坏它，添加属性肯定会这样做。） / p>
如果您避免指定serialVersionUID，javac会在其中放置一些类似于该类哈希的独特内容。
什么时候重要？当您将内容序列化到磁盘并希望稍后使用不同版本的程序加载它时。 或者当两个可能具有不同版本的实例需要通过线路交换序列化数据时。
如果你不使用实际的序列化而你的类只是Serializable，因为它继承了那个接口，那么避免使用serialVersionUID是最容易和最安全的事情。如果您进行序列化但不需要与过去兼容，那也是相同的，在这种情况下，避免使用值是最安全的事情。
另一方面，如果您需要加载使用过去修订版生成的内容（远程或自己，从磁盘上长期遗忘的文件），那么您需要具有该值并且需要小心谨慎什么时候（并且只在什么时候）确实破坏了兼容性。
在第二次评论之后添加（由Robin发布）：
不回答实际问题。
呃，对。我想这是一个：没有，据我所知，实际数字没有任何意义，它只需要与以前的所有以前的值不同，当它与它们不再兼容时。
此外，您应该始终为Serializable类声明serialVersionUID
作为一般性建议，我认为避免它是一个更好的解决方案：大多数时候你不需要与不同供应商的JVM交谈，你不需要对很久以前或实际需要的数据进行反序列化兼容性检查，大多数时候序列化对象是非常短暂的。
当然，对于不同的项目来说可能会有很大不同，当你拥有长期序列化对象时，你必须承担定义这些UID并正确维护它们的负担。 / p>
但是，由于缺少UID意味着“快速失败，捕获错误”，而使用1L（或任何其他常数）通常意味着“班级改变，你不记得更新它，后来出现问题”，然后作为一般建议，我认为第一个是更好的默认值。
答案 1 :(得分：3)
“真正的”serialVersionUID的唯一用途是用于后备兼容性。如果是新类，请使用您想要的任何编号系统。
我个人认为使用简单的数字方案可以更容易地阅读和比较版本之间的数字变化。通过工具创建的哈希值对于机器来说是好的，但不是人类友好的。一个简单的一个编号方案对两者都很有用，毕竟机器并不关心这个或那个。