Java Optional 链式取值怎么避免误判：orElse、orElseGet 与异常边界

订单详情接口里，用户没有配置优惠券时通常要回退到默认策略。很多 Java 代码会把这件事写成 optional.orElse(loadDefaultRule())，看起来直白，实际上默认规则会先被计算，即使 Optional 里已经有值。这个小差异在默认值需要查库、读文件或调用远程服务时，就可能变成额外耗时甚至副作用。

orElse 为什么会提前计算默认值

orElse 接收的是一个已经求值的普通对象，而不是一段等待调用的函数。下面的示例即使 name 有值，也会先执行 loadFallbackName()：

String name = Optional.of("Lin")
        .orElse(loadFallbackName());

static String loadFallbackName() {
    System.out.println("fallback loaded");
    return "guest";
}

最终结果仍然是 Lin，但日志会打印 fallback loaded。如果默认值只是一个常量，这通常没有实际问题；如果它包含数据库查询、对象组装、埋点或远程调用，提前执行就会带来不必要的成本。这里的重点不是“orElse 永远不能用”，而是要确认参数求值是否有代价。

orElseGet 如何把回退逻辑变成懒执行

orElseGet 接收 Supplier，只有 Optional 没有值时才会调用它：

String name = Optional.ofNullable(loadUserName())
        .orElseGet(() -> loadFallbackName());

当上游返回非空值时，传入的回退函数不会运行。对于订单优惠券、租户配置和本地缓存这类“通常有值、缺失时才查默认来源”的代码，懒执行能减少无意义的资源开销，也更容易在测试里核对副作用的触发次数。

不过 Supplier 也不是零成本的抽象。不要把复杂业务流程全部塞进 lambda；默认值逻辑超过一两行时，提取成命名清晰的独立方法更容易后续维护和复用。还要避免在 Supplier 中悄悄修改共享状态，否则调用时机不透明会让问题更难排查。

orElseThrow 适合表达必填数据缺失

有些数据缺失不属于正常回退场景，而是请求无法继续的错误信号。例如订单编号不存在时，返回空订单对象会把错误推迟到更深的业务层才暴露出来。可以直接把缺失转换成明确的业务异常：

Order order = orderRepository.findById(orderId)
        .orElseThrow(() -> new OrderNotFoundException(orderId));

Supplier 形式的 orElseThrow 同样是懒执行：只有 Optional 为空时才创建异常。异常类型应该贴近接口语义，控制器再把它映射为稳定的 404 或业务错误码。不要为了省事写成 orElseThrow() 后让调用方只能看到通用的 NoSuchElementException，除非这正是你要暴露的边界。

把三种写法放进同一张选择表

如果默认值已经在变量里准备好了，orElse(existingValue) 不存在额外的“提前计算”问题；问题发生在把有副作用的表达式直接作为参数时。审查代码时应看表达式本身，而不是只根据方法名字下结论。

用调用次数测试确认懒执行边界

可以用一个计数器验证回退函数是否只运行在空值路径：

AtomicInteger calls = new AtomicInteger();
Supplier fallback = () -> {
    calls.incrementAndGet();
    return "guest";
};

assertEquals("Lin", Optional.of("Lin").orElseGet(fallback));
assertEquals(0, calls.get());
assertEquals("guest", Optional.empty().orElseGet(fallback));
assertEquals(1, calls.get());

再补一组 orElseThrow 测试：有值时异常 Supplier 不应运行，空值时应得到约定的异常类型和订单编号。这样测试验证的是执行契约，而不只是最终字符串。

常见问题

orElse 一定比 orElseGet 慢吗？

不一定。差异取决于默认表达式的成本以及实际是否走空值分支。廉价常量用 orElse 更直观；默认值需要计算或访问外部资源时，orElseGet 才能避免有值路径的额外工作。

Optional 可以替代所有 null 判断吗？

不建议这种用法。Optional 更适合表达方法返回值可能缺失的边界，不要把它塞进实体字段或用多层 Optional 链遮住原本清晰的业务判断。调用方仍然要明确缺失数据对应的实际业务含义。

什么时候应该使用 orElseThrow？

当缺失数据意味着请求无法完成，或者继续返回默认对象会生成错误结果时使用。自定义异常应有稳定类型，并在接口边界层转换成开发者和用户都能理解的响应。

把空值处理写成可验收的接口契约

orElse、orElseGet 和 orElseThrow 的区别不只是语法偏好，而是默认值求值时机和缺失数据含义的区别。先判断回退逻辑是否有成本或副作用，再选择懒执行；当缺失本身是错误时，用明确异常终止流程。最后用调用次数、异常类型和有值/空值两条路径做验收，Optional 才不会变成隐藏问题的包装层。