加了Serializable仍抛NotSerializableException是因为类中存在未实现Serializable的成员变量或未处理static/transient字段；serialVersionUID不写会导致类结构变化时反序列化失败；原生序列化存在安全与兼容性问题，建议优先使用JSON等替代方案。
为什么加了 Serializable 还抛 NotSerializableException
加了接口只是“声明可序列化”，不代表对象真能被序列化。常见原因是类里有未实现 Serializable 的成员变量（比如 Thread、Socket、自定义非序列化类），或用了 static / transient 字段但没意识到它们不参与序列化。
实操建议：
- 用
ObjectOutputStream写对象前，先检查所有非transient非static字段的类型是否都实现了Serializable - 对不可序列化的字段（如数据库连接、回调函数）显式标为
transient - 如果字段类型是你自己写的类，确保它也声明了
Serializable，且其所有非transient字段也满足条件 - IDE 通常会在字段上标黄警告，别忽略
serialVersionUID 不写会怎样？什么时候必须手动指定
不写时 JVM 会根据类结构自动生成一个 serialVersionUID，但只要类稍作修改（比如加个字段、改个访问修饰符），生成的值就可能变，导致反序列化时抛 InvalidClassException：class invalid because serialVersionUID mismatch。
实操建议：
- 所有实现
Serializable的类，都应显式声明private static final long serialVersionUID = 1L;（数值可自定义，但一旦发布上线，就别再改） - 如果类结构稳定、仅用于临时缓存或单次进程内传输，可以不写；但凡涉及磁盘存储、网络传输、跨版本兼容，就必须写
- 用 IDE 自动生成（IntelliJ 快捷键 Alt+Enter → “Add ‘serialVersionUID’ field”）比手写更可靠，避免手误
用 ObjectOutputStream 和 ObjectInputStream 做最简序列化/反序列化
这是 JDK 原生方式，适合简单场景，但要注意流必须配对关闭，且反序列化时类路径必须存在（否则 ClassNotFoundException）。
实操建议：
- 序列化示例：
try (FileOutputStream fos = new FileOutputStream("obj.ser"); ObjectOutputStream oos = new ObjectOutputStream(fos)) { oos.writeObject(myObj); } - 反序列化示例：
try (FileInputStream fis = new FileInputStream("obj.ser"); ObjectInputStream ois = new ObjectInputStream(fis)) { MyObj obj = (MyObj) ois.readObject(); } - 务必用 try-with-resources 确保流关闭，否则可能锁住文件或泄露句柄
- 反序列化前确认
myObj类在当前 classpath 下可用，尤其在模块化或热部署环境里容易出问题
替代方案：为什么有时候不该用 Java 原生序列化
原生序列化耦合强、安全性低（反序列化可触发任意代码执行）、性能一般、跨语言差。Spring、Dubbo、Kafka 等框架默认已禁用或替换它。
实操建议：
- 对外暴露的 API、微服务间通信、持久化到数据库或 Redis，优先选 JSON（
jackson/gson）、Protobuf 或 Avro - 若必须用原生序列化（如老系统改造），至少开启
SecurityManager或用ObjectInputFilter（Java 9+）限制反序列化类型 - 注意：
ArrayList、HashMap等 JDK 类虽实现了Serializable，但内部用了很多transient字段 + 自定义writeObject，不要以为“能序列化”就等于“结构透明”
