如何利用 Optional.orElse() 精妙应对方法可能返回 null 的情况？

本文共计874个文字，预计阅读时间需要4分钟。

很多人一看到 `Optional.orElse(())` 这种方法就想去用它来代替 `null`，结果发现返回的是 `null`。这其实是因为这个方法只对 `Optional` 类型有效。如果返回的是 `String`、`Integer` 或自定义对象，它不会按预期工作。根本原因在于这个方法只适用于 `Optional` 类型，而对于其他类型，如 `String`、`Integer` 或自定义对象，它并不会将它们转换为 `Optional`，因此无法调用 `orElse` 方法。

正确路径是：先确保方法本身返回 Optional，或者手动包装原始值。否则强行写 someMethod().orElse("default") 会报错 cannot resolve method 'orElse(String)'。

把 null-returning 方法改造成返回 Optional 是最干净的解法

与其在调用方反复做 if (x == null) 判断，不如让提供方承担“是否可空”的契约责任。比如把：

public User findUserById(Long id) { return userRepository.findById(id); // 可能返回 null }

改成：

public Optional<User> findUserById(Long id) { User user = userRepository.findById(id); return Optional.ofNullable(user); }

之后调用就真正“优雅”了：

• findUserById(123L).orElse(new User("anonymous")) —— 值不存在时给默认对象
• findUserById(123L).orElseGet(() -> createUserIfMissing(123L)) —— 延迟计算，默认值构造开销大时用
• findUserById(123L).map(User::getName).orElse("Unknown") —— 链式转换后兜底，避免 NPE

别在非 Optional 上硬套 orElse()，常见错误写法

以下写法全都不合法，且容易被 IDE 或静态检查工具忽略（尤其在泛型擦除或类型推导模糊时）：

• someStringMethod().orElse("default") —— someStringMethod() 返回 String，没有 orElse 方法
• Optional.of(someMethod()).orElse("fallback") —— 如果 someMethod() 返回 null，Optional.of(null) 直接抛 NullPointerException
• Optional.ofNullable(someMethod()).orElse(null) —— 语义混乱，兜底为 null 失去 Optional 意义，不如直接用原始值

真正安全的包装只有 Optional.ofNullable(...)，但它只是起点，不是银弹。

orElse() 和 orElseGet() 的性能与副作用差异必须看清

两者都用于提供默认值，但执行时机不同，这直接影响副作用和性能：

• orElse(new HeavyObject())：无论 Optional 是否有值，HeavyObject() 构造函数都会执行
• orElseGet(() -> new HeavyObject())：仅当值为空时才执行 lambda，无额外开销
• 如果默认值是常量（如 "N/A"、0），用 orElse 更直白；如果是数据库查询、IO 或复杂计算，必须用 orElseGet

另外注意：orElseThrow() 虽然也是兜底，但它不处理 null 场景，而是把空值显式转成异常，适合“空即错误”的强契约场景。

真正容易被忽略的是：Optional 不是 null 的语法糖，它是建模“存在性”的类型。强行把所有 null 返回方法都包一层 Optional.ofNullable 调用，反而会让调用链失去意图——该明确抛异常的地方包了 Optional，该允许空值的地方又没用 Optional，比直接判 null 还难维护。