or 返回 Optional 而非值，须配合 Optional 链式操作；ifPresentOrElse 的 else 分支应表达业务语义而非简单抛异常；map 不防 null，flatMap 才是 Optional 链中真正的 null 过滤器。
用 or 替代 orElseGet 时的常见误用
很多人以为 or 就是 orElseGet 的语法糖，其实它返回的是 Optional 而非实际值。如果你写成 opt.or(() -> Optional.of(new User()))，后续还得调 get() 或 map，反而增加嵌套层级。
真正适合 or 的场景是「需要延续 Optional 链式操作」：比如从缓存查不到就查 DB，但查 DB 的结果本身也是 Optional<user></user>，这时用 or 才自然：
cache.get(id).or(() -> db.findUserById(id))
注意两点：
• or 的 lambda 必须返回 Optional，不能直接 new 对象
• 如果 DB 层返回的是 User（非 Optional），得先包装：`() -> Optional.ofNullable(db.load(id))`
ifPresentOrElse 比 ifPresent 多出来的那个 else 分支怎么写才不破坏可读性
ifPresentOrElse 的设计本意是强制你处理「空」的情况，但很多人一上来就塞个 throw new RuntimeException(...)，这等于把空指针异常换了个马甲，没解决业务语义问题。
真正该做的是让两个分支都表达明确意图：
- 成功分支做核心逻辑（如更新状态、发消息）
- 失败分支写「这个空意味着什么」——是参数非法？资源已删除？还是上游系统未就绪？
示例：
userOpt.ifPresentOrElse(
u -> notifyService.sendWelcome(u.getEmail()),
() -> log.warn("welcome skipped: user {} not found", id)
);
这里没抛异常，也没 return，而是记录一个带上下文的 warn 日志——因为「用户不存在」在这个流程里是合法状态，不是错误。
为什么链式调用中混用 get() 和 orElse 是空指针温床
下面这段代码看着安全，实则藏雷：
String name = userOpt.map(User::getProfile)
.map(Profile::getName)
.orElse("Anonymous");
问题出在 User::getProfile 返回 Profile（非 Optional），如果 getProfile() 本身返回 null，map 就会抛 NPE —— 因为 map 不会自动跳过 null，它只对 Optional 为空时短路。
正确做法只有两个：
- 确保中间 getter 全部返回
Optional（推荐，但需改接口） - 用
flatMap+Optional.ofNullable补救：flatMap(u -> Optional.ofNullable(u.getProfile()))
记住：map 不防 null，flatMap 才是 Optional 链里真正的 null 过滤器。
业务方法返回 Optional 时，哪些地方必须加判空，哪些可以放心链下去
不是所有返回 Optional 的方法都适合直接链式消费。关键看它的语义是否「天然可选」：
- ✅ 适合链式：数据库查询（
findById）、缓存读取（get）、配置项解析（getConfig）——这些操作本身就可能无结果 - ❌ 不适合链式：构造器、计算函数（如
calculateTotal(items)）——它们返回Optional.empty()往往是异常信号，该立刻中断或告警
一个硬指标：如果方法文档里写了「当 X 不存在时返回 empty」，那它就是为链式设计的；如果只说「返回结果或 null」，那它只是把 null 包了一层 Optional，本质还是老式防御式编程。
最易被忽略的一点：Spring Data JPA 的 findById 返回 Optional，但 save 和 findAll 不返回 —— 别因为前者用了 Optional，就误以为整个 Repository 都适配函数式风格。
