不用担心，默认计算非常好，可以满足999999%的情况。如果你遇到问题，你可以——正如已经说过的——在需要时引入UID（这是极不可能的）

不用担心，默认计算非常好，可以满足999999%的情况。如果你遇到问题，你可以——正如已经说过的——在需要时引入UID（这是极不可能的）

每次序列化对象时，对象都会标记对象类的版本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章。

我通常在一个上下文中使用serialVersionUID：当我知道它将离开JavaVM的上下文时。

当我为我的应用程序使用ObjectInputStream和ObjectOutputStream时，或者如果我知道我使用的库/框架将使用它时，我会知道这一点。serialVersionID确保不同版本或供应商的不同Java VM能够正确互操作，或者如果它在VM外部存储和检索（例如HttpSession），会话数据即使在应用服务器。

对于所有其他情况，我使用

@SuppressWarnings("serial")

因为大多数时候默认的serialVersionUID就足够了。这包括异常、HttpServlet。

简单解释：

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

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

如果您在一个从未想过序列化的类上收到此警告，并且您没有声明自己实现了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方法。我认为在这种情况下不应该有警告（因为你通常无法可靠地序列化和反序列化这些匿名类，不管是在你的类的不同版本中），但我不确定编译器如何识别这一点。