关键在默认值生成是否带开销：orElse强制执行，orElseGet按需触发；复合对象初始化易踩坑因其常含DB查询、远程调用等非内存操作，orElse会无谓浪费资源。
关键不在“用哪个”，而在“默认值生成是否带开销”。当复合对象初始化涉及构造函数调用、i/o、远程调用或复杂计算时，orelse 会强制执行，orelseget 则按需触发——这个差异在高频或资源敏感场景下可能造成数倍性能落差。
复合对象初始化为什么容易踩坑
复合对象（如 User、OrderDetail、ApiResponse）往往依赖多层嵌套构造、字段校验、数据库关联查询或第三方服务调用。这类初始化不是简单 new 一个对象，而是可能触发：
- 数据库连接与 SQL 执行（如加载默认配置）
- HTTP 客户端发起远程请求（如获取兜底用户信息）
- 反射创建 + 初始化块 + 后置处理器（如 Spring Bean 构造）
- 大量临时对象分配（如 JSON 解析、集合填充）
这些操作一旦被 orElse 提前执行，就变成纯浪费——哪怕 Optional 里明明有值。
真实代码对比：一眼看出执行时机差异
假设有一个耗时的兜底用户构建逻辑：
private User buildFallbackUser() {
System.out.println("→ 正在加载兜底用户（含DB查询+缓存回源）");
return userRepo.findOrCreateDefault();
}
两种写法行为完全不同：
-
optionalUser.orElse(buildFallbackUser())：无论 optionalUser 是否存在，都会打印那行日志并执行 DB 查询 -
optionalUser.orElseGet(this::buildFallbackUser)：仅当 optionalUser 为 empty 时，才打印日志、查库
在 QPS 达到数百的接口中，前者可能每秒多发数百次无意义 DB 请求；后者则零冗余。
什么情况必须用 orElseGet
以下任意一条成立，就该立刻替换为 orElseGet：
- 默认值构造方法名含
load、fetch、create、from等动词，且内部有非内存操作 - 构造逻辑包含
new RestTemplate().getForObject(...)或jdbcTemplate.query(...) - Lambda 表达式体超过一行，或调用了非纯函数（如含日志、计数器、锁）
- 对象创建后立即调用
init()、validate()或触发监听器
什么时候 orElse 反而更合适
并非 all-in orElseGet。以下场景用 orElse 更清晰、安全：
- 返回常量对象，如
orElse(Collections.emptyMap())、orElse(ImmutableList.of()) - 使用静态工厂方法且无副作用，如
orElse(User.anonymous())（该方法只 new + 赋默认值） - 默认值是基本类型或字符串字面量：
orElse(0)、orElse("N/A") - 团队明确约定所有
orElse参数必须是无状态、无 IO、无外部依赖的表达式
此时语义更直白，JVM 也更容易内联优化，无需 Supplier 包装开销。
