Optional.orElseThrow()通过Supplier延迟创建并抛出业务异常，精准中断流程；应优先用Lambda动态构造含上下文的异常，避免复用或提前捕获，确保语义明确、诊断信息完整。

直接用 Optional.orElseThrow() 并传入一个自定义异常的 Supplier，就能在值为空时立即抛出业务异常，中断后续流程。

传入 Lambda 创建具体异常

最常用的方式是用 Lambda 表达式构造并返回一个新异常实例：

• userOpt.orElseThrow(() -> new UserNotFoundException("用户ID " + userId + " 未找到"));
• 异常类型可以是自定义的运行时异常（如 UserNotFoundException），无需显式 try-catch，符合业务中断语义
• Lambda 延迟执行——仅当 Optional 为 empty 时才触发，避免无谓的对象创建

复用已有异常实例（慎用）

如果异常不含动态参数，可提前创建再复用：

• final UserNotFoundException notFound = new UserNotFoundException("用户不存在");
• userOpt.orElseThrow(() -> notFound);
• 注意：不能直接写 orElseThrow(notFound)，因为方法签名要求的是 Supplier，不是异常对象本身
• 不推荐用于含上下文信息（如 ID、时间戳）的异常，否则会丢失关键诊断数据

配合业务校验链使用

常与其他 Optional 操作串联，实现清晰的空值防护逻辑：

• return userOpt.filter(User::isActive)

•     .orElseThrow(() -> new InvalidUserException("用户已停用或不存在"));
• 先 filter 再 orElseThrow，确保抛出的异常语义精准（不只是“没找到”，而是“找到了但不可用”）
• 避免在 orElseThrow 后再做判空或 if-check，违背了 Optional 的设计初衷

不要和 try-catch 混用做流程控制

除非上层明确要捕获并转换异常，否则不应包裹 orElseThrow：

• ❌ 错误示范：try { return opt.orElseThrow(...); } catch (UserNotFoundException e) { throw new ServiceException(e); }
• ✅ 正确做法：让异常自然向上冒泡，由统一异常处理器（如 Spring 的 @ControllerAdvice）处理响应格式
• 业务异常本就该中断流程，强行 catch 反而模糊了错误边界，增加维护成本