实施序列化时要小心

积累知识，胜过积蓄金银！毕竟在文章开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《实施序列化时要小心》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

1. 简单实现，潜在风险巨大

• 只需添加序列化功能，就能轻松实现可序列化类。
• 然而，序列化可能带来巨大的长期维护成本。

2. 类演化与兼容性

• 一旦类被序列化，其序列化格式就成为了公共API的一部分。
• 内部修改可能会破坏与旧版本的兼容性。
• 虽然可以通过手动维护兼容性（ObjectOutputStream.putFields 和 ObjectInputStream.readFields），但这过程复杂且容易出错。

3. SerialVersionUID 的重要性

• 每个可序列化类都需要一个唯一的标识符 (SerialVersionUID)。
• 如果没有手动指定，编译器会自动生成。
• 类的任何更改都可能改变此 ID，从而导致兼容性问题并抛出 InvalidClassException 异常。

4. 安全隐患

• 序列化绕过了构造函数，可能规避语言限制。
• 可能创建具有无效值的对象，或允许未授权的访问。
• 对未经验证的序列化数据的依赖可能导致安全漏洞（参见项目88）。

5. 测试复杂性增加

• 需要在不同版本之间测试可序列化的类。
• 可序列化的类越多，所需的测试矩阵就越大。
• 预期的序列化结构难以演变。

6. 序列化必要性

• 序列化对于需要持久化数据的框架是必要的。
• 在值类（例如 BigInteger，Instant）和集合中很有用。
• 表示活动过程的类（例如 ThreadPool）通常不应序列化。

7. 序列化与继承

• 为继承而设计的类通常不应序列化。
• 接口应尽量避免扩展序列化，因为它会对未来的实现施加额外的限制。
• 值得注意的例外：可抛出异常（用于 RMI 异常传播）和组件（用于 Swing/AWT）。

8. 内部类问题

• 由于未指定的合成字段，内部类不应序列化。
• 静态成员类可以实现序列化。

9. 序列化的替代方案

• 使用自定义序列化机制（参见项目90）以获得更好的控制。
• 使用 JSON 或 XML 等格式进行持久化和数据传输。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《实施序列化时要小心》文章吧，也可关注golang学习网公众号了解相关技术文章。