Java Optional.or 怎么串联备用值：Supplier 惰性计算与异常边界

用户资料服务通常不只有一个来源：先查本地缓存，没命中再查数据库，数据库没有记录时才去请求归档服务。把这条链直接写成嵌套的 orElseGet，很快就会遇到返回类型不一致和备用查询提前执行的问题。Java 的 Optional.or 正好适合串联“仍然返回 Optional 的下一级查询”，而且只有当前一级为空时才会调用 Supplier。

先把多级查询的责任边界摆清楚

假设订单详情页要找一个用户昵称，查询顺序是 cache、database、archive。每个方法都返回 Optional，调用方只关心“第一个可用结果”。传统写法容易把值先拆出来，再为下一层重新组装 Optional，代码长了以后，哪一层负责空值判断并不明显。

Optional displayName = fromCache(userId)
        .or(() -> fromDatabase(userId))
        .or(() -> fromArchive(userId));

这段代码表达的是选择顺序，不是并行查询。缓存命中时，数据库和归档查询都不会发生；缓存未命中但数据库命中时，只会执行前两层。

命中时为什么能证明 Supplier 没有提前执行

排查线上性能问题时，不要只看最终昵称，还要记录备用方法是否真的被调用。可以先用一个计数器做最小实验：

AtomicInteger databaseCalls = new AtomicInteger();
AtomicInteger archiveCalls = new AtomicInteger();

Optional result = Optional.of("cache-name")
        .or(() -> {
            databaseCalls.incrementAndGet();
            return Optional.of("db-name");
        })
        .or(() -> {
            archiveCalls.incrementAndGet();
            return Optional.of("archive-name");
        });

System.out.println(result.orElseThrow());
System.out.println(databaseCalls); // 0
System.out.println(archiveCalls);  // 0

or 的返回值仍然是 Optional，所以链可以继续；但 orElseGet 的 Supplier 返回的是最终值，二者不能混用。这里先保留 Optional，等选择链结束后再决定是抛异常、返回默认值还是转换成响应对象。

空值会沿着链走，返回 null 则是契约错误

缓存未命中时应该返回 Optional.empty()，而不是直接返回 null。前者表示“可以继续问下一层”，后者破坏了 Optional 的契约：

Optional result = Optional.empty()
        .or(() -> Optional.empty())
        .or(() -> Optional.of("archive-name"));

// result = Optional[archive-name]

Optional broken = Optional.empty()
        .or(() -> null); // NullPointerException

这个异常不是“没有备用结果”，而是供应函数实现错误。实际项目里应让数据访问层统一返回 Optional.empty()，并在单元测试中覆盖“空结果继续查找”和“禁止 null 返回”两条路径。

异常不会被 or 自动变成空结果

如果数据库连接失败，数据库 Supplier 抛出的异常会直接向外传播，归档 Supplier 不会因为异常自动接管。这样设计可以避免把真实故障误判成普通未命中：

Optional result = fromCache(userId)
        .or(() -> fromDatabase(userId))
        .or(() -> fromArchive(userId));

只有“明确没有这条记录”才适合用 Optional.empty() 表达；超时、权限失败、连接中断等问题应保留异常语义，交给服务层决定是否告警、重试或返回降级结果。若业务确实允许归档服务兜底，可以在数据库边界捕获经过确认的异常并记录原因，但不要把所有 RuntimeException 都转为空。

or、orElseGet 和 orElse 怎么选

三者都能看到“备用值”，但层次不同：

• or：备用函数返回 Optional，用于继续拼接查询链。
• orElseGet：备用函数返回 T，用于链结束后的惰性默认值。
• orElse：直接传入默认值，默认值表达式会先被求值，适合成本很低的常量。

String name = fromCache(userId)
        .or(() -> fromDatabase(userId))
        .orElseGet(() -> "匿名用户");

如果默认值构造过程会查库、读文件或拼接大对象，优先用 orElseGet。如果只是一个字面量，orElse("匿名用户") 更直白。别用 or 替代异常处理，它解决的是 Optional 的空结果组合，不是故障恢复策略。

把验证写成四个可复查的测试

上线前至少验证四件事：有值时备用查询计数为零；空值时按顺序进入下一层；供应函数返回 null 时立即失败；供应函数抛错时异常保持原类型。示例中的计数器可以换成 Mockito 的验证，也可以直接用测试替身记录调用顺序。

if (!Optional.of("db-name").equals(
        Optional.empty().or(() -> Optional.of("db-name")))) {
    throw new IllegalStateException("unexpected fallback value");
}

if (!Optional.empty().or(() -> Optional.empty()).isEmpty()) {
    throw new IllegalStateException("empty result changed");
}

try {
    Optional.empty().or(() -> null);
    throw new IllegalStateException("null supplier was accepted");
} catch (NullPointerException expected) {
    // 供应函数返回 null，立即失败
}

try {
    Optional.empty().or(() -> {
        throw new IllegalStateException("database unavailable");
    });
    throw new IllegalStateException("database error was hidden");
} catch (IllegalStateException expected) {
    if (!"database unavailable".equals(expected.getMessage())) {
        throw new IllegalStateException("wrong error message", expected);
    }
}

测试名称最好直接写出状态，例如“cache hit does not call database”和“database error is not treated as miss”。这样失败时能迅速看出是选择逻辑变了，还是数据源的错误分类变了。

常见问题

Optional.or 是 Java 哪个版本加入的？

它在 Java 9 加入，Java 25 API 仍保留相同的核心语义：当前有值就返回当前 Optional，否则调用供应函数生成下一个 Optional。

Supplier 返回空 Optional 后会怎样？

空 Optional 会继续交给后面的 or；如果链结束仍为空，再由 orElseGet、orElseThrow 或其他终结操作处理。

可以用 or 捕获数据库异常吗？

不可以自动捕获。数据库 Supplier 抛出的异常会传播到调用方；是否降级要在数据访问层或服务层明确决定，并保留可观测的错误原因。

为什么不能写成 or(() -> null)？

因为 or 要求 Supplier 产出一个非 null 的 Optional。没有结果请返回 Optional.empty()，否则就是实现契约被破坏。

收束查询链，保留故障语义

Optional.or 的价值在于把多级“可能没有结果”的查询写成一条惰性链：命中就停，未命中才继续。把正常空结果与连接失败、超时等异常分开表达，再用调用计数和异常断言做验收，这条链才既简洁又能在生产排查时说明白发生了什么。