如果您在一个从未想过序列化的类上收到此警告，并且您没有声明自己实现了Serializable，这通常是因为您继承了一个实现Serializable的超类。通常情况下，最好委托给这样的对象，而不是使用继承。

所以

public class MyExample extends ArrayList<String> {

    public MyExample() {
        super();
    }
    ...
}

do

public class MyExample {
    private List<String> myList;

    public MyExample() {
         this.myList = new ArrayList<String>();
    }
    ...
}

并且在相关方法中调用myList.foo（）而不是this.foo（）（或super.foo（（））

我经常看到有人在扩展JFrame之类的东西，而实际上他们只需要授权。（这也有助于在IDE中自动完成，因为JFrame有数百个方法，当您想在类中调用自定义方法时，不需要这些方法。）

警告（或serialVersionUID）不可避免的一种情况是，从AbstractAction（通常在匿名类中）扩展时，只添加actionPerformed方法。我认为在这种情况下不应该有警告（因为你通常无法可靠地序列化和反序列化这些匿名类，不管是在你的类的不同版本中），但我不确定编译器如何识别这一点。

如果您想修改大量最初没有设置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用于对象的版本控制。也可以在类文件中指定serialVersionUID。不指定serialVersionUID的结果是，当您添加或修改类中的任何字段时，已经序列化的类将无法恢复，因为为新类和旧序列化对象生成的serialVersionID将不同。Java序列化过程依赖于正确的serialVersionUID来恢复序列化对象的状态，并在serialVersionID不匹配的情况下抛出Java.io.InvalidClassException

阅读更多信息：http://javarevisited.blogspot.com/2011/04/top-10-java-serialization-interview.html#ixzz3VQxnpOPZ

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

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

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

如果CheckStyle能够验证实现Serializable的类上的serialVersionUID是否具有良好的值，即它与串行版本id生成器将生成的值相匹配，这将是一件好事。例如，如果您有一个包含大量可序列化DTO的项目，那么记住删除现有的serialVersionUID并重新生成它是一件痛苦的事，而目前验证这一点的唯一方法（据我所知）是为每个类重新生成并与旧类进行比较。这是非常痛苦的。

要理解字段serialVersionUID的重要性，应该了解序列化/反序列化的工作原理。

当序列化一个Serializable类对象时，Java Runtime将一个序列版本号（称为serialVersionUID）与这个序列化对象相关联。在反序列化此序列化对象时，Java Runtime将序列化对象的serialVersionUID与类的serialVersion UID匹配。如果两者都相等，则只有它继续执行进一步的反序列化过程，否则抛出InvalidClassException。

因此，我们得出结论，要使序列化/反序列化过程成功，序列化对象的serialVersionUID必须与类的serialVersion UID等效。如果程序员在程序中显式指定serialVersionUID值，那么无论序列化和反序列化平台如何，相同的值都将与序列化对象和类相关联（例如，可以使用sun或MS JVM在类似windows的平台上进行序列化，而反序列化可以使用Zing JVM在不同的平台Linux上进行）。

但是，如果程序员未指定serialVersionUID，则在对任何对象进行Serialization\DeSerialization时，Java运行时会使用自己的算法来计算它。这种serialVersionUID计算算法因JRE而异。对象序列化的环境也可能使用一个JRE（例如：SUN JVM），而取消序列化的环境则使用LinuxJvm（zing）。在这种情况下，与序列化对象关联的serialVersionUID将不同于在取消序列化环境中计算的类的serialVersion UID。反过来，反序列化将不会成功。所以为了避免这种情况/问题，程序员必须始终指定Serializable类的serialVersionUID。