应使用 orElseGet 而非 orElse，因为 orElse 会立即执行默认值构造，导致每次无谓查库；orElseGet 仅在 Optional 为空时才调用 Supplier，适合延迟加载数据库默认配置，兼顾性能与兜底可靠性。
用 Optional.orElseGet 加载数据库动态配置的默认值，核心在于把“查库失败时的兜底逻辑”延迟执行，并与配置加载流程自然融合——既避免无谓查询，又保证空配置时有合理回退。
为什么不用 orElse 而选 orElseGet
orElse 会**立即执行**传入的对象构造（比如 new XxxConfig() 或调用静态方法），哪怕 Optional 非空；而 orElseGet 接收的是 Supplier，只在 Optional 为空时才调用，适合做开销较大、依赖外部资源（如数据库）的操作。
例如：
- ❌
configRepo.findByKey("timeout").orElse(loadDefaultTimeoutFromDb())→ 每次都查库，不管有没有配置 - ✅
configRepo.findByKey("timeout").orElseGet(() -> loadDefaultTimeoutFromDb())→ 仅当 key 不存在时才查库
典型实现结构：分层加载 + 缓存友好
真实场景中，配置往往需支持多级 fallback（如：应用配置 > 数据库配置 > 硬编码默认值），同时兼顾性能。推荐结构如下：
- 先查本地缓存（如 Caffeine）→ 命中则直接返回
- 未命中则查数据库 → 返回 Optional
- 用
orElseGet触发降级逻辑：可查另一张 default_config 表，或读取配置类中的常量，甚至调用远程配置中心
示例代码片段：
public Integer getTimeout(String key) {
return configCache.get(key, k ->
configRepo.findByKey(k)
.map(ConfigEntity::getValueAsInt)
.orElseGet(() -> defaultConfigService.getDefaultValueAsInt(k))
);
}
注意 null 安全与类型一致性
orElseGet 的 Supplier 返回类型必须和 Optional 的泛型类型一致。若数据库实体字段允许为 null，需在 map 阶段显式处理，否则 map 后可能得到 Optional.empty()，触发 orElseGet —— 这未必是预期行为。
建议写法：
- 数据库查询返回
Optional.ofNullable(entity.getValue())，而非裸 entity - map 中做非空校验：
.map(v -> v != null ? v : null)，再用 filter 过滤掉 null 值 - 或统一约定：数据库 null 值 = 该配置未设置，应走 orElseGet；而 0/-1 等是有效值
结合 Spring Boot 的实用技巧
若使用 Spring Data JPA，可让 Repository 方法直接返回 Optional；搭配 @Cacheable 注解时，注意 orElseGet 内部逻辑不应被缓存代理拦截（它本就不该缓存）。
进阶建议：
- 将 orElseGet 中的降级逻辑封装为独立 Service 方法，便于单元测试和监控调用频次
- 对 orElseGet 的 DB 查询加超时和熔断（如用 Resilience4j），防止降级路径拖垮主流程
- 记录 orElseGet 被触发的次数和 key，作为配置治理的数据依据
