orElseThrow比orElse更适合抛异常场景，因为后者强制提供冗余兜底值，而前者专为“空值即错误”设计；应传Supplier\<Throwable\>实现懒加载，避免提前构造异常或执行副作用。
orElseThrow 为什么比 orElse 更适合抛异常场景
因为 orElse 要求你提供一个“兜底值”，哪怕你只想抛异常，也得先构造一个无意义的对象再丢弃——这不仅冗余，还可能触发不必要的初始化或副作用。而 orElseThrow 是专为“空值即错误”设计的，它不期待返回值，只专注表达“这里必须有值，否则就炸”。
如何用 Supplier 抛出自定义异常（Java 8+）
关键在传入一个 Supplier<Throwable>，不是直接 new 异常对象。否则异常会在 Optional 创建时就构造，哪怕值存在也会执行——这是最常踩的坑。
- ✅ 正确写法：
optional.orElseThrow(() -> new IllegalArgumentException("用户ID不能为空")) - ❌ 错误写法：
optional.orElseThrow(new IllegalArgumentException("用户ID不能为空"))（编译不过，类型不匹配） - ⚠️ 更隐蔽的错：
optional.orElseThrow(() -> { log.warn("missing user"); return new RuntimeException(); })（日志总被打印，不管 optional 是否为空）
Java 10+ 的简化写法：直接传异常构造器引用
如果自定义异常有无参构造函数，可以用方法引用进一步精简，但注意：它只适用于无参构造，且无法带动态消息。
- 适用：
optional.orElseThrow(MyException::new)（MyException必须有 public 无参构造） - 不适用：
optional.orElseThrow(() -> new MyException("id=" + id))这种带变量的，仍需 Lambda - 性能提示：方法引用比 Lambda 略轻量，但差异微乎其微，优先选可读性
和 ifPresent + throw 的对比：别用 if 判断再手动 throw
有人习惯先 if (!optional.isPresent()) throw ...，这看似直观，但多了一次判空调用，且破坏了 Optional 的链式表达意图。更严重的是，在并发或副作用场景下，isPresent() 和后续取值之间可能存在竞态——值在两次调用间被清空，导致 NPE。
- ✅ 推荐：
optional.map(User::getName).orElseThrow(() -> new IllegalStateException("用户名缺失")) - ❌ 避免：
if (!optional.isPresent()) throw ...; String name = optional.get().getName(); - 注意：
get()本身就会抛NoSuchElementException，但它是通用异常，语义弱；自定义异常才能精准传达业务意图
