orElseGet 延迟执行 Supplier，仅在 Optional 为空时才查 Redis 缓存；orElse 则无论是否有值都会立即计算参数，导致冗余 Redis 调用。
用 Optional.orElseGet 结合本地 Redis 缓存加载默认值，核心在于：把“从 Redis 读取缓存”封装成一个 Supplier，交给 orElseGet 延迟执行——只在原值为空时才查缓存，避免无谓的 Redis 调用。
为什么不用 orElse 而用 orElseGet？
orElse(T other) 会**立即计算**参数值，无论 Optional 是否有值；orElseGet(Supplier extends T> supplier) 则是**惰性求值**——仅当 Optional 为 empty 时才调用 Supplier。在涉及 Redis 查询这类 I/O 操作时，这点至关重要：
- 若用
orElse(redisService.get("key"))，每次都会触发一次 Redis 请求，哪怕 Optional 已含有效值 - 改用
orElseGet(() -> redisService.get("key"))，Redis 只在真正缺失时才查，性能更可控
典型场景：配置项兜底加载
比如业务中需要读取一个开关配置，优先用内存变量（如 Spring 的 @Value 注入），失败则查本地 Redis，再失败才用硬编码默认值：
String featureFlag = Optional.ofNullable(localConfig.getFeatureFlag())
.or(() -> Optional.ofNullable(redisService.get("config:feature:flag")))
.orElseGet(() -> "false"); // 最终兜底
注意：这里用了 or() 组合两个 Optional，比嵌套 orElseGet 更清晰。但若只有 Redis 一层兜底，直接用：
String value = Optional.ofNullable(userInput)
.orElseGet(() -> redisService.get("cache:user:default:theme"));
配合序列化与类型安全的写法
Redis 存的是字符串或字节数组，实际使用时常需反序列化。建议将反序列逻辑封装进 Supplier，保持外部简洁：
User defaultUser = Optional.ofNullable(currentUser)
.orElseGet(() -> {
String json = redisService.get("user:default");
return json != null ? objectMapper.readValue(json, User.class) : new User("guest", "default");
});
这样既延迟了 Redis 查询，也把 JSON 解析、空值判断、构造默认对象等逻辑收束在 Supplier 内部，主流程干净可读。
注意事项与避坑点
使用过程中需留意几个关键细节：
- Redis 连接异常要兜住：Supplier 内必须捕获 JedisConnectionException 等，否则异常会直接抛出，破坏 Optional 的语义
- 避免重复 key 查询：如果多个地方都用相同 key 查默认值，建议抽成工具方法，统一加日志和熔断逻辑
-
null 值在 Redis 中的表示：有些 Redis 客户端对 null 返回 "" 或抛异常，需提前约定并处理，否则
orElseGet可能误判 - 本地缓存 vs Redis 缓存：标题说“本地 Redis 缓存”，实际 Redis 是远程服务；如真指本地 Caffeine/Guava 缓存，用法一致，但响应更快、更安全
不复杂但容易忽略：Supplier 的执行时机和异常边界，决定了这个模式是否真正可靠。
