orelse() 仅适用于 optional 类型，不能直接替代 null 检查；正确做法是让方法返回 optional 或用 optional.ofnullable 包装，避免在非 optional 上调用 orelse()。
orElse() 不能直接替代 null 检查，它只作用于 Optional 实例
很多人一看到 Optional.orElse() 就想拿它“兜底”方法返回的 null，结果发现编译不通过或逻辑出错——根本原因是：这个方法只对 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);
}</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 还难维护。
