orElseThrow()仅在“空值即非法状态”时使用，如配置必存、ID必对应实体；应抛具体异常（如UserNotFoundException），避免RuntimeException穿透；不适用于DTO校验等空值合法场景。
Optional.orElseThrow() 不是异常处理的替代品
它只是把“取不到值”这个逻辑分支显式转成异常，不改变异常传播路径，也不参与 try-catch 的流程控制。用错地方反而会让调用方更难捕获真正该处理的业务异常。
常见错误现象：Optional.ofNullable(user).orElseThrow(() -> new RuntimeException("user not found")) 被塞进 service 层主逻辑，结果 RuntimeException 穿透到 controller，掩盖了本该返回 404 的语义。
- 只在「空值即非法状态」时用，比如：配置项必须存在、ID 必须对应实体、缓存 key 必须命中
- 抛出的异常类型要具体，避免泛泛用
RuntimeException；推荐自定义如UserNotFoundException - 别在流式操作中间链式调用
orElseThrow()，一旦触发就中断整个 stream，且异常堆栈指向 lambda 内部，难定位
orElseThrow() 和 ifPresent() + throw 的行为差异
表面看都是“没值就抛异常”，但字节码和可读性差很多：前者是单次判断 + 抛出，后者是先判断再执行 lambda，多一次函数调用开销，且 IDE 很难推断 lambda 中的异常意图。
使用场景：当你需要明确表达“此处必须有值，否则流程崩溃”，而不是“我先看看有没有，没有就手动处理”。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
optional.orElseThrow(IllegalStateException::new)编译后是直接 check + athrow -
optional.ifPresentOrElse(u -> {}, () -> { throw new IllegalStateException(); })多一层方法分派 - 参数差异：前者支持 Supplier
，后者只能写完整 lambda；Supplier 更易复用，比如 MISSING_CONFIG::exception
和传统 null 检查比，什么情况下值得用 orElseThrow()
不是为了“看起来函数式”，而是为消除歧义：null 是临时缺失、还是根本不存在、还是未初始化？orElseThrow() 明确表示“这里不该为空”。
性能影响几乎可忽略（JVM 对 Optional 优化很好），但要注意兼容性——Java 8+ 才有带 Supplier 的重载，Java 8 早期版本只有无参 orElseThrow()，强制抛 NoSuchElementException。
- 适合：DAO 返回 Optional、配置加载器、解析 JSON 字段时用
JsonNode.path("id").<code>isMissingNode()后转 Optional - 不适合：DTO 字段校验、HTTP 请求参数解析（这些场景空值是合法输入，该走
@NotNull或 if 判断） - 容易踩的坑：把
Optional.empty().orElseThrow()放在循环里，每次调用都新建异常对象，GC 压力比预想的大
嵌套 Optional 场景下 orElseThrow() 的陷阱
Optional 本身不能嵌套（Optional<optional>></optional> 是反模式），但业务代码里常出现“从 Optional 里再 map 出一个 Optional”，这时候直接链式 orElseThrow() 会让人误以为外层非空即可，其实内层可能 still empty。
示例：userOpt.map(User::getProfile).map(Profile::getAvatarUrl).orElseThrow() —— 这里抛异常的条件是 avatarUrl 为空，不是 user 为空，语义已经偏移。
- 正确做法：拆开判断，或用
flatMap扁平化，确保最终 Optional 是你要的那层 - 调试时注意：IDE 的 Optional 链式调用提示容易高亮错位置，实际断点得打在 map 内部
- 如果真需要多层 fallback，优先考虑
Optional.or(() -> Optional.ofNullable(fallback()))（Java 9+），而不是层层 orElseThrow
最易被忽略的一点：orElseThrow() 的 Supplier 是惰性求值，但异常构造本身不是——哪怕你写 () -> new ExpensiveException(loadConfig())，只要 Optional 为空，loadConfig() 就一定会执行。别让它偷偷拖慢主流程。
