optional仅适用于方法返回值，禁用于实体字段、构造参数和setter入参；避免多层flatmap链式调用；优先使用orelseget而非orelse以防性能隐患；禁用get()和ispresent()+get()反模式；注意第三方库对optional支持有限。
Optional 不是万能的，别用它包装所有可能为 null 的字段
很多人一听说 Optional 就想把它当“null 安全银弹”，甚至给每个 getter 都改成返回 Optional<string></string>。这反而破坏了语义——如果一个字段本就允许为空、且业务逻辑中明确需要区分“未设置”和“设为空字符串”，那用 Optional 反而模糊了意图；更严重的是，Optional 是不可序列化的，放进 JSON 或存进数据库前必须解包，否则会抛 NotSerializableException 或输出无意义的 "Optional[...]" 字符串。
- 只在「方法返回值」中使用
Optional，尤其是那些可能找不到结果的查找操作（如findById、findByName） - 不要用
Optional作为实体类字段类型，也不要用于构造函数参数或 setter 入参 - 避免链式调用
optional1.flatMap(...).flatMap(...)超过三层，可读性急剧下降，此时应考虑拆成带明确命名的中间变量
用 orElse 和 orElseGet 的区别决定性能与副作用
这两个方法看起来都提供“默认值”，但触发时机完全不同：orElse(T other) 无论 Optional 是否有值都会执行参数表达式；而 orElseGet(Supplier extends T> other) 只在值为空时才调用 supplier。如果默认值生成开销大（比如查一次数据库、解析一个大 JSON），用错就会埋下性能隐患。
Optional<User> user = userRepository.findById(123);
// ❌ 每次都执行 new User("guest")，即使 user 存在
User result1 = user.orElse(new User("guest"));
// ✅ 仅当 user 为空时才创建 guest 实例
User result2 = user.orElseGet(() -> {
log.warn("User not found, creating guest");
return new User("guest");
});
警惕 get() 和 isPresent() + get() 这种反模式
Optional.get() 在空值时直接抛 NoSuchElementException，等于把 NPE 换了个名字；而先 isPresent() 再 get() 则违背了 Optional 的设计初衷——它不是让你写 if-else 的替代品，而是鼓励你用函数式方式处理分支。
- 优先用
map/flatMap做转换，用ifPresent做消费，用orElse/orElseGet提供兜底 - 需要条件逻辑时，用
filter配合后续操作，而不是手动判空 - 真要 throw 异常，用
orElseThrow(() -> new RuntimeException("..."))，语义清晰且可定制异常类型
第三方库（如 Lombok、MapStruct）对 Optional 的支持有限
Lombok 的 @Data 会为 Optional 字段生成不安全的 toString() 和 equals() 方法；MapStruct 在映射含 Optional 的 DTO 时，默认不会自动解包，需显式配置 @Mapping(target = "name", source = "user.name.orElse(null)") 或自定义 Mapper 方法。
立即学习“Java免费学习笔记（深入）”；
更隐蔽的问题是：Spring Data JPA 的 QueryByExampleExecutor 返回 Optional，但如果你在 service 层又套了一层 Optional.ofNullable(...)，就可能让原本空的结果变成非空的 Optional.empty()，导致上层误判。
真正难的从来不是怎么写 Optional，而是什么时候不该写、以及写完之后整个调用链是否还保持语义一致——尤其在跨模块、跨团队协作时，一个随意暴露 Optional 的 API，很可能迫使下游用 .get() 硬解，前功尽弃。
