Optional未实现Serializable接口，不可用于字段序列化；应仅作方法返回值，实体类需用原始类型+Optional.ofNullable()包装。
因为 Optional 类的设计定位就是“方法返回值的契约容器”，不是用于持久化或跨进程传输的数据载体，所以它**没有实现 Serializable 接口**，也没有声明 serialVersionUID，内部字段也未做序列化适配。
它本质上是个轻量级不可序列化的工具类
Optional 的源码里只有两个关键字段：private final T value 和一个静态空实例 EMPTY。它既没有实现 writeObject / readObject，也没重写序列化语义；更关键的是，它的构造器是私有的，且 value 字段没有 transient 修饰——但 JVM 默认序列化机制在遇到未实现 Serializable 的类型时，会直接抛 NotSerializableException，连走到字段检查那步都进不去。
JDK 官方明确不建议它作字段使用
- JavaDoc 原话：“It is not intended for use as a field type”（不应用于字段类型）
- 作为字段时，一旦所在类参与 RMI、Redis 缓存、Dubbo 序列化、甚至
ObjectOutputStream直接写文件，都会因Optional不可序列化而失败 - 即使 Jackson 等框架能“兼容”Optional 字段（靠模块如
jackson-datatype-jdk8），那也只是 JSON 层的特殊处理，和 Java 原生序列化无关
替代方案要分场景说清楚
- 需要序列化的实体类：用原始类型 + 显式 null 或可空包装（如
String、Integer），由业务层调用时再包成Optional.ofNullable() - DTO/VO 层：保持字段朴素，JSON 中字段可缺省，前端或调用方按协议约定处理缺失
- 流式计算或链式处理：放心用
Optional作返回值，这是它最该在的地方
一句话收尾：Optional 是编译期的空值契约，不是运行时的数据载体；它解决的是“怎么写得更安全、更可读”，而不是“怎么存得更持久、传得更远”。
