Optional应仅作返回值表达“可能不存在”，禁用于字段、参数等场景；正确创建只用ofNullable()；orElseGet优于orElse；flatMap解决Optional嵌套；Optional不可序列化，DTO中应避免使用。
Optional不是万能的，别把它当null的包装器用
Java 8引入Optional的本意是**作为返回值类型，表达“可能不存在”的契约**，而不是用来替代所有null场景。把它塞进字段、集合、方法参数或数据库映射字段里，反而会增加理解成本和运行时开销。常见错误包括：new Optional<String>(null)（编译不通过）、Optional.of(null)（立刻抛NullPointerException）、或在Map.get()后无脑套一层Optional.ofNullable()却不处理语义——这没解决空问题，只掩盖了设计缺陷。
正确创建Optional：只用ofNullable()，避开of()和empty()的误用场景
Optional.of()要求参数非null，适合你**100%确定值存在**的内部逻辑（比如刚new出来的对象）；Optional.empty()只是静态常量，无需每次new；而真正该高频使用的只有Optional.ofNullable()——它安全封装可能为null的值，并统一后续处理路径。
String value = getValueFromDB(); // 可能为null Optional<String> opt = Optional.ofNullable(value); // ✅ 安全 // ❌ 错误：value可能是null，of()会炸 // Optional<String> opt = Optional.of(value); // ✅ 如果你确信非null（比如刚set过的bean字段） Optional<String> safeOpt = Optional.of(result.trim());
链式调用时警惕orElse()和orElseGet()的性能陷阱
orElse(T other)无论Optional是否含值，都会执行other的计算（比如新建对象、查数据库）；而orElseGet(Supplier<? extends T> other)只在为空时才调用Supplier。性能差异在重操作中非常明显。
-
opt.orElse(new HeavyObject())→ 每次都构造HeavyObject -
opt.orElseGet(() -> new HeavyObject())→ 仅为空时构造 -
opt.orElseThrow(() -> new RuntimeException("missing"))→ 推荐写法，语义清晰
另外，get()必须配合isPresent()使用，否则等于换种方式写if (x != null)——违背了Optional的初衷。直接用ifPresent()或map()/flatMap()才是正解。
立即学习“Java免费学习笔记（深入）”；
与Stream和函数式接口配合时，flatMap比map更关键
当你的转换逻辑本身也返回Optional（比如根据id查用户，再查其部门），用map()会导致Optional<Optional<Dept>>嵌套；必须用flatMap()展平：
Optional<User> userOpt = findUserById(123);
Optional<Dept> deptOpt = userOpt
.flatMap(user -> findDeptById(user.getDeptId())); // ✅ 返回Optional<Dept>
// ❌ 错误：得到Optional<Optional<Dept>>
// Optional<Optional<Dept>> wrong = userOpt.map(user -> findDeptById(user.getDeptId()));
这种嵌套一旦出现，后续几乎只能靠orElse(null)硬解，等于白用Optional。
最易被忽略的一点：Optional本身不可序列化，且Spring Data JPA等框架对Optional返回值有特定约定（如Repository方法返回Optional<Entity>会被自动处理），但自定义DTO里放Optional字段会导致Jackson序列化失败或MyBatis映射异常——这时候老老实实用@Nullable注解加文档说明，比强行套壳更务实。
