如果您想修改大量最初没有设置serialVersionUID的类，同时保持与旧类的兼容性，IntelliJ Idea、Eclipse等工具会产生随机数，并且不能一次性处理一堆文件，因此会出现问题。我提出了以下bash脚本（很抱歉，Windows用户，请考虑购买Mac或转换为Linux），以轻松解决serialVersionUID问题：

base_dir=$(pwd)                                                                  
src_dir=$base_dir/src/main/java                                                  
ic_api_cp=$base_dir/target/classes                                               

while read f                                                                     
do                                                                               
    clazz=${f//\//.}                                                             
    clazz=${clazz/%.java/}                                                       
    seruidstr=$(serialver -classpath $ic_api_cp $clazz | cut -d ':' -f 2 | sed -e 's/^\s\+//')
    perl -ni.bak -e "print $_; printf qq{%s\n}, q{    private $seruidstr} if /public class/" $src_dir/$f
done

保存此脚本时，将add_serialVersionUID.sh设置为~/bin。然后在Maven或Gradle项目的根目录中运行它，如下所示：

add_serialVersionUID.sh < myJavaToAmend.lst

此.lst包含用于以以下格式添加serialVersionUID的java文件列表：

com/abc/ic/api/model/domain/item/BizOrderTransDO.java
com/abc/ic/api/model/domain/item/CardPassFeature.java
com/abc/ic/api/model/domain/item/CategoryFeature.java
com/abc/ic/api/model/domain/item/GoodsFeature.java
com/abc/ic/api/model/domain/item/ItemFeature.java
com/abc/ic/api/model/domain/item/ItemPicUrls.java
com/abc/ic/api/model/domain/item/ItemSkuDO.java
com/abc/ic/api/model/domain/serve/ServeCategoryFeature.java
com/abc/ic/api/model/domain/serve/ServeFeature.java
com/abc/ic/api/model/param/depot/DepotItemDTO.java
com/abc/ic/api/model/param/depot/DepotItemQueryDTO.java
com/abc/ic/api/model/param/depot/InDepotDTO.java
com/abc/ic/api/model/param/depot/OutDepotDTO.java

该脚本使用了JDK serialVer工具。因此，请确保$JAVA_HOME/bin位于PATH中。

如果您永远不需要将对象序列化到字节数组并发送/存储它们，那么您就不必担心。如果需要，那么您必须考虑serialVersionUID，因为对象的反序列化程序会将其与其类加载器所具有的对象版本相匹配。在Java语言规范中了解更多有关它的信息。

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

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

什么时候重要？

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

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

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

serialVersionUID有助于序列化数据的版本控制。序列化时，其值与数据一起存储。反序列化时，将检查同一版本，以查看序列化数据与当前代码的匹配情况。

如果要对数据进行版本化，通常从serialVersionUID 0开始，并将其与更改序列化数据（添加或删除非瞬时字段）的类的每一个结构更改一起转储。

内置的反序列化机制（在.defaultReadObject（）中）将拒绝从旧版本的数据进行反序列化。但如果您愿意，您可以定义自己的readObject（）函数，该函数可以读取旧数据。然后，此自定义代码可以检查serialVersionUID，以了解数据的版本，并决定如何对其进行反序列化。如果存储的序列化数据在代码的几个版本中都存在，则此版本控制技术非常有用。

但将序列化数据存储如此长的时间跨度并不常见。更常见的是使用串行化机制将数据临时写入例如缓存，或通过网络将数据发送到具有相同版本的代码库相关部分的另一个程序。

在这种情况下，您对保持向后兼容性不感兴趣。您只关心确保正在通信的代码库确实具有相同版本的相关类。为了方便这种检查，您必须像以前一样维护serialVersionUID，并且在对类进行更改时不要忘记更新它。

如果忘记更新字段，则可能会导致一个类的两个不同版本具有不同的结构，但具有相同的serialVersionUID。如果发生这种情况，默认机制（在.defaultReadObject（）中）将检测不到任何差异，并尝试对不兼容的数据进行反序列化。现在，您可能会遇到一个神秘的运行时错误或静默失败（空字段）。这些类型的错误可能很难找到。

因此，为了帮助这个用例，Java平台为您提供了不手动设置serialVersionUID的选择。相反，类结构的哈希将在编译时生成并用作id。该机制将确保您永远不会有具有相同id的不同类结构，因此您不会得到上述难以跟踪的运行时序列化失败。

但自动生成id策略也有其背后的原因。也就是说，为同一类生成的id在编译器之间可能会有所不同（正如Jon Skeet所提到的）。因此，如果在使用不同编译器编译的代码之间传递序列化数据，建议无论如何都手动维护id。

如果您像前面提到的第一个用例那样与数据向后兼容，那么您可能也希望自己维护id。这是为了获得可读的id，并更好地控制它们的更改时间和方式。

什么是serialVersionUID，为什么要使用它？

SerialVersionUID是每个类的唯一标识符，JVM使用它来比较类的版本，以确保在序列化期间使用的相同类在反序列化期间加载。

指定一个可以提供更多控制，但如果不指定，JVM会生成一个。不同编译器生成的值可能不同。此外，有时您只是出于某种原因想要禁止旧序列化对象的反序列化[向后不兼容]，在这种情况下，您只需更改serialVersionUID。

Serializable的javadocs表示：

默认的serialVersionUID计算对类高度敏感详细信息可能因编译器实现而异因此，在反序列化。

因此，您必须声明serialVersionUID，因为它给了我们更多的控制权。

这篇文章在这个话题上有一些好的观点。

每次序列化对象时，对象都会标记对象类的版本ID号。此ID称为serialVersionUID，它是根据有关类结构的信息计算的。假设您创建了一个Employee类，它的版本id为#333（由JVM分配），现在当您将序列化该类的对象（假设Employees对象）时，JVM将为其分配UID为#333。

考虑一种情况——将来您需要编辑或更改类，在这种情况下，当您修改它时，JVM将为它分配一个新的UID（假设#444）。现在，当您尝试反序列化雇员对象时，JVM会将序列化对象（雇员对象）的版本ID（#333）与类的版本ID进行比较，即#444（自更改以来）。相比之下，JVM将发现两个版本UID不同，因此反序列化将失败。因此，如果每个类的serialVersionID由程序员自己定义。即使类在未来演变，它也将是相同的，因此JVM将始终发现类与序列化对象兼容，即使类已更改。有关更多信息，请参阅HEAD FIRST JAVA的第14章。