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<x></x>，不是异常对象本身 - 不推荐用于含上下文信息（如 ID、时间戳）的异常，否则会丢失关键诊断数据
配合业务校验链使用
常与其他 Optional 操作串联，实现清晰的空值防护逻辑：
return userOpt.filter(User::isActive)</li> <li> .orElseThrow(() -> new InvalidUserException("用户已停用或不存在"));</li> <li>先 filter 再 orElseThrow，确保抛出的异常语义精准（不只是“没找到”，而是“找到了但不可用”）</li> <li>避免在 orElseThrow 后再做判空或 if-check，违背了 Optional 的设计初衷</li> </ul> <H3>不要和 try-catch 混用做流程控制</H3> <p>除非上层明确要捕获并转换异常，否则不应包裹 orElseThrow：</p> <ul> <li>❌ 错误示范：<code>try { return opt.orElseThrow(...); } catch (UserNotFoundException e) { throw new ServiceException(e); }- ✅ 正确做法：让异常自然向上冒泡，由统一异常处理器（如 Spring 的
@ControllerAdvice）处理响应格式 - 业务异常本就该中断流程，强行 catch 反而模糊了错误边界，增加维护成本
