java序列化是将对象及其类结构、字段值、继承链等完整转为字节流，反序列化则逆向还原；notserializableexception源于字段引用不可序列化类型；需用transient或自定义write/readobject处理；未显式声明serialversionuid会导致类变更时invalidclassexception；jdk原生序列化因格式私有、安全风险、兼容性差、性能低，生产环境应慎用。
Java序列化就是把对象变成字节流，反序列化就是把字节流变回对象——它不是“存数据”那么简单，而是完整保存对象的类结构、字段值、甚至继承链信息。
ObjectOutputStream.writeOject() 为什么一调就抛 NotSerializableException？
这个异常不是因为你忘了写代码，而是 JVM 在运行时发现某个字段指向了不可序列化的类型。常见原因包括：
- 类没实现
Serializable接口（最基础要求） - 某个实例变量是
Thread、Socket、Connection等系统资源类，它们本身没实现接口 - 用了匿名内部类或 Lambda 表达式，其隐式引用了外部类，而外部类未序列化
- 父类没实现
Serializable，子类虽实现了，但父类字段不会被自动序列化（除非父类也实现）
解决办法很简单：给不该序列化的字段加 transient 修饰符；对必须保留状态的资源类，手动在 writeObject() / readObject() 中处理。
serialVersionUID 不显式声明会怎样？
不写，JVM 会按类名、方法签名、字段等自动生成一个哈希值。一旦你改了字段名、删了方法、加了新字段，哪怕只是加个注释，这个值就变了——反序列化时直接报 InvalidClassException: class invalid for deserialization。
立即学习“Java免费学习笔记（深入）”；
所以建议始终显式定义：
private static final long serialVersionUID = 1L;
注意：1L 可以，但上线项目最好用 IDE 自动生成的 64 位长整数（如 -8725093427384320001L），避免多人开发时手误导致版本错乱。
为什么生产环境慎用 JDK 原生序列化？
它快、简单、不用额外依赖，但有硬伤：
- 字节流格式私有且不跨语言——Python 或 Go 服务根本读不了
.ser文件 - 反序列化过程会执行类的静态初始化块和构造器，存在反序列化 gadget 风险（比如 Apache Commons Collections 利用链）
- 类结构稍有变动就失败，升级兼容性差；没有字段默认值机制，新增字段会导致旧客户端反序列化失败
- 性能上比 JSON/Protobuf 差不少，尤其字段多、嵌套深时，二进制体积反而更大
真实场景中，RPC（如 Dubbo）默认已切到 Hessian 或 Kryo；缓存（Redis）基本都用 JSON；只有本地临时文件或测试 demo 才用 ObjectOutputStream。
真正难的从来不是“怎么写”，而是“什么时候不该写”——比如把 HttpServletRequest 或 Spring 的 ApplicationContext 往里塞，或者以为加个 Serializable 就万事大吉，结果上线后某次字段重命名，凌晨三点收到告警。
