Java Optional避免嵌套空判断

我在整理一段“读取用户所在城市”的接口代码时，最先看到的不是业务问题，而是一层套一层的 null 判断：用户可能没有地址，地址可能没有城市，城市名称还可能是空字符串。Java Optional 避免嵌套空判断的关键，不是把每个变量机械地包成 Optional，而是让每一层转换都沿着一条链继续传递，最后再统一决定“给默认值”还是“明确失败”。

官方 API 参考：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/Optional.html

本文用一个真实感的故障复盘来拆解这次改法：普通 getter 用 map，已经返回 Optional 的查询用 flatMap，默认值需要计算时用 orElseGet，必填数据则用 orElseThrow。

先看症状：空判断为什么越改越深

最初的实现能工作，但每增加一层对象就多出一个缩进。维护者很容易漏掉某个层级，或者在找到城市后忘记过滤空白名称。

// 旧写法：每一层都要单独判断，新增字段会继续增加缩进
String cityName = "未知城市";
if (profile != null) {
    Address address = profile.getAddress();
    if (address != null) {
        City city = address.getCity();
        if (city != null && city.getName() != null && !city.getName().isBlank()) {
            // 只有所有对象都存在且名称非空时才返回业务值
            cityName = city.getName();
        }
    }
}

这段代码的根因不是 if 不能用，而是“对象不存在”和“业务默认值”混在了同一段控制流里。我们先把问题拆成四个可能为空的节点，再让 Optional 链表达这条关系。

用 map 把普通对象读取收口成一条链

如果 getter 返回的是普通对象或字符串，使用 map 最直接。Oracle 的 API 说明中，map 会在有值时执行转换；转换结果为 null 时，结果会变成 empty，因此不需要在每个 getter 后再写一层判断。

// map 负责把每个普通 getter 的结果接到下一层 Optional
String cityName = Optional.ofNullable(profile)
        .map(Profile::getAddress)       // profile 为空时，后面的 getter 不会调用
        .map(Address::getCity)          // address 为空时，链直接变为空
        .map(City::getName)             // city 或 name 为空都会继续得到 empty
        .filter(name -> !name.isBlank()) // 把空白名称也视为没有有效城市
        .orElse("未知城市");             // 只在链为空时给出展示层默认值

经验是把默认值放在链的最后。这样“读取关系”仍然清楚，默认值也不会被误当成下一层输入。如果默认值不是简单常量，而是需要访问缓存或构造对象，就不要急着写 orElse。

查询方法已经返回 Optional 时改用 flatMap

复盘中的第二个问题来自仓储层：findById 本身已经返回 Optional

// 仓储方法已经返回 Optional，不能再用 map 叠一层包装
Optional cityName = Optional.ofNullable(profile)
        .map(Profile::getAddressId)              // 先得到可能为空的地址编号
        .flatMap(addressRepository::findById)    // 直接接入 Optional

        .map(Address::getCity)
        .map(City::getName)
        .filter(name -> !name.isBlank());        // 空结果仍由链统一表达

可以这样记：map 的函数返回普通值，flatMap 的函数已经返回 Optional。两者都只在当前 Optional 有值时调用映射函数；区别在于是否需要保留一层包装。

链末端的选择：orElse、orElseGet 还是 orElseThrow

Optional 链只是把“有没有值”表达清楚，业务决定仍然要在末端完成。常量默认值可以用 orElse；默认值需要执行查询、构造或记录日志时用 orElseGet，因为 Supplier 只会在 Optional 为空时调用。

// 默认值计算有成本时，使用 orElseGet 避免无意义的调用
String displayName = user.map(User::getDisplayName)
        .filter(name -> !name.isBlank())
        .orElseGet(() -> { // 只有没有有效名称时才加载兜底名称
            return nicknameService.loadDefaultName();
        });

// 订单必须存在时，用异常表达业务约束，而不是悄悄返回空对象
Order order = orderRepository.findById(orderId)
        .orElseThrow(() -> new OrderNotFoundException(orderId)); // 保留明确的失败原因

如果把“必填数据缺失”也改成一个看似正常的默认对象，故障会被推迟到更远的地方。相反，orElseThrow 让接口边界立即暴露问题。get() 在空值时抛出 NoSuchElementException，不利于携带业务上下文，通常不如带异常 Supplier 的 orElseThrow。

修复后的边界：Optional 不要扩散到所有地方

这次改造后，调用链更短了，但我没有把每个实体字段都改成 Optional。Oracle API 的定位是：Optional 主要适合作为明确表示“可能没有结果”的方法返回类型；Optional 变量本身不应再是 null。实体字段、序列化 DTO 和方法参数是否采用 Optional，还要考虑框架绑定、数据库映射和调用方成本。

可以把规则收敛为三点：

• 普通 getter 返回普通值时用 map，返回 Optional 时用 flatMap。
• 只在链的末端选择默认值或异常，不在中途把默认对象塞回链中。
• 对外返回“可能无结果”时使用 Optional，对内部字段和参数不要为了消灭一个 null 就全面包装。

最后回到标题问题：Java Optional 避免嵌套空判断，最有价值的变化是把“每层是否为空”的控制流，变成一条可读的数据转换关系。先用 map/flatMap 描述路径，再用 filter 表达有效性，最后用 orElseGet 或 orElseThrow 做业务选择，代码才不会只是换了一种写法。

相关问题

map 和 flatMap 最容易混淆的地方是什么？

看映射函数的返回类型：返回普通对象用 map，返回 Optional 用 flatMap，后者会避免出现嵌套 Optional。

orElseGet 一定比 orElse 更好吗？

不是。常量或已经准备好的值用 orElse 更直观；只有默认值计算有副作用或成本时，才用 orElseGet 延迟执行。