serialVersionUID作用：
相当于java类的身份证。主要用于版本控制。
serialVersionUID作用是序列化时保持版本的兼容性，即在版本升级时反序列化仍保持对象的唯一性。
序列化时为了保持版本的兼容性，即在版本升级时反序列化仍保持对象的唯一性。
有两种生成方式：
一个是默认的1L，比如：private static final long serialVersionUID = 1L;
一个是根据类名、接口名、成员方法及属性等来生成一个64位的哈希字段，比如：
private static final long serialVersionUID = xxxxL;
serialVersionUID是可序列化类的一个版本标识，在反序列化的时候使用这个标识的值来判断序列化和反序列化的对象类型是否一致。Java的序列化机制是通过在运行时判断类的serialVersionUID来验证版本一致性的。在进行反序列化时，JVM会把传来的字节流中的serialVersionUID与本地相应实体（类）的serialVersionUID进行比较，如果相同就认为是一致的，可以进行反序列化，否则就会出现序列化版本不一致的异常（InvalidClassException）。当你一个类实现了Serializable接口，如果没有定义serialVersionUID，Eclipse会提供这个提示功能告诉你去定义之。
总结（重点思考）
工作中我们经常在进行持久化操作和返回数据时都会使用到javabean来统一封装参数，方便操作，一般我们也都会实现Serializable接口，那么问题来了，首先：为什么要进行序列化；其次：每个实体bean都必须实现serializabel接口吗？最后：我做一些项目的时候，没有实现序列化，同样没什么影响，到底什么时候应该进行序列化操作呢？
网上找了很多资料，但是感觉大都没有说的很清楚，所以结合自己的理解做一下总结。
首先第一个问题，实现序列化的两个原因：1、将对象的状态保存在存储媒体中以便可以在以后重新创建出完全相同的副本；2、按值将对象从一个应用程序域发送至另一个应用程序域。实现serializabel接口的作用是就是可以把对象存到字节流，然后可以恢复，所以你想如果你的对象没实现序列化怎么才能进行持久化和网络传输呢，要持久化和网络传输就得转为字节流，所以在分布式应用中及设计数据持久化的场景中，你就得实现序列化。
第二个问题，是不是每个实体bean都要实现序列化，答案其实还要回归到第一个问题，那就是你的bean是否需要持久化存储媒体中以及是否需要传输给另一个应用，没有的话就不需要，例如我们利用fastjson将实体类转化成json字符串时，并不涉及到转化为字节流，所以其实跟序列化没有关系。
第三个问题，有的时候并没有实现序列化，依然可以持久化到数据库。这个其实我们可以看看实体类中常用的数据类型，例如Date、String等等，它们已经实现了序列化，而一些基本类型，数据库里面有与之对应的数据结构，从我们的类声明来看，我们没有实现serializabel接口，其实是在声明的各个不同变量的时候，由具体的数据类型帮助我们实现了序列化操作。
另外需要注意的是，在NoSql数据库中，并没有与我们java基本类型对应的数据结构，所以在往nosql数据库中存储时，我们就必须将对象进行序列化，同时在网络传输中我们要注意到两个应用中javabean的serialVersionUID要保持一致，不然就不能正常的进行反序列化。