orElseThrow 应仅用于业务不可接受的空值异常，如订单ID为空查库、用户凭证缺失等，需抛出带上下文的具体业务异常，而非泛化RuntimeException；其他场景应选用 orElse、ifPresentOrElse 或 or 等更匹配的方法。
用 orElseThrow 解决“必填变量缺失”问题，关键不是“有空就抛”，而是精准识别哪些空值属于**业务不可接受的异常状态**——比如订单ID为空却要查库、用户凭证必须存在但返回null、支付渠道配置缺失却要发起扣款。这类场景下，orElseThrow 能把隐性错误显性化、把模糊失败转为可追溯的业务异常。
明确“必须存在”的业务语义
别在任意空值处都加 orElseThrow。先问自己：这个空，是参数传错了？上游系统故障？还是设计上就允许缺省？只有当空代表“流程无法继续、结果必然错误”时，才适用。
- ✅ 合理：查询核心用户信息失败 →
orElseThrow(() -> new UserNotFoundException("ID: " + id)) - ✅ 合理：获取支付密钥为空 →
orElseThrow(PaymentKeyMissingException::new) - ❌ 过度：获取用户头像URL为空 → 应用
orElse("default-avatar.png")，而非抛异常
用 Supplier 构造带上下文的业务异常
避免写 orElseThrow(RuntimeException::new)。异常类型要具体，消息要含关键字段，方便排查。
- 写法正确：
.orElseThrow(() -> new OrderValidationException("订单" + orderId + "未通过风控校验")) - 写法危险：
.orElseThrow(() -> new RuntimeException("fail"))—— 日志里看不出谁、哪步、为什么失败 - 进阶技巧：在 lambda 中记录审计日志或上报监控，再抛异常，实现“失败即留痕”
嵌套调用中守住最后一道防线
多层 flatMap 链中，最外层用 orElseThrow 收口，比每一步都判空更安全、更简洁。
例如：查用户 → 查其认证信息 → 查认证绑定的银行卡号
User user = userService.findById(userId)
.flatMap(u -> authService.getCredentials(u.getId()))
.flatMap(c -> bankService.getPrimaryCard(c.getUserId()))
.orElseThrow(() -> new BankAccountNotBoundException("用户" + userId + "未绑定主卡"));
这段代码天然规避了中间任意一环为 null 导致的 NPE，且异常语义清晰：不是“找不到用户”，而是“用户已存在，但主卡未绑定”——这才是业务真正关心的失败原因。
和 ifPresentOrElse / orElse 分工协作
orElseThrow 不是万能兜底，它只负责“中断流程+报错”。其他情况交给更适合的 API：
- 需要提供默认值 → 用
orElse("默认城市")或orElseGet(this::loadDefaultConfig) - 需要对“有/无”分别执行副作用（如发消息/打日志）→ 用
ifPresentOrElse(u -> send(u), () -> log.warn("跳过通知：用户不存在")) - 需要 fallback 到另一路 Optional 查询（如缓存未命中查 DB）→ 用
or(() -> dbQuery())
混用这些方法，才能让每种空值处理方式各司其职，不越界、不冗余。
