Optional 本身不是异常处理机制，但能与 Stream 配合显式化“可能为空”的逻辑，避免空指针异常、减少 try-catch 滥用，实现干净可控的降级路径；它适用于值存在性判断，不适用于 IO、网络、业务校验等操作失败场景。
Optional 本身不是异常处理机制，但它能和流（Stream）配合，把“可能为空”的逻辑显式化，从而避免空指针异常，减少 try-catch 的滥用，实现更干净、更可控的降级路径。
用 map + orElseGet 替代可能抛 NPE 的链式调用
当 Stream 处理中涉及嵌套对象取值（如 user.getAddress().getCity()），直接调用极易触发 NullPointerException。用 Optional 封装源头，再结合惰性求值，可自然跳过异常分支：
推荐写法：
String city = Optional.ofNullable(user)
.map(User::getAddress)
.map(Address::getCity)
.orElseGet(() -> {
log.warn("User {} has no city, using default", user.getId());
return "Unknown City";
});
这样既不抛异常，也不打断流处理流程；默认值只在真正需要时才计算，避免资源浪费。
立即学习“Java免费学习笔记（深入）”；
在 Stream.filter / map 中用 Optional 隔离风险操作
对集合做流式转换时，某些元素可能因数据不全导致中间操作失败。与其 try-catch 整个 forEach，不如把单个元素的“安全提取”封装进 Optional：
- 用 Optional.ofNullable(...).map(...).filter(...).isPresent() 控制是否保留该元素
- 或统一返回 Optional，再用 flatMap(Optional::stream) 过滤掉空结果
示例：从用户列表中提取有效邮箱，跳过 null 或格式非法项
List<String> validEmails = users.stream()
.map(user -> Optional.ofNullable(user.getEmail())
.filter(email -> email.contains("@")))
.flatMap(Optional::stream)
.collect(Collectors.toList());
整个过程无异常、无中断，天然支持“失败即忽略”的降级语义。
与自定义工具方法组合，统一兜底策略
把常见降级逻辑（如查缓存失败→查DB→返回默认）封装成返回 Optional 的工具方法，再接入 Stream 流水线：
- 避免在 lambda 里写 try-catch，把异常处理下沉到工具层
- 让流操作只关注“有值怎么处理”，不关心“没值怎么救”
- 后续可统一替换为异步/熔断版本，不影响上层流结构
例如：
public static Optional<Config> safeLoadConfig(String key) {
try {
return Optional.ofNullable(configService.getByKey(key));
} catch (RemoteException e) {
log.error("Config load failed for {}", key, e);
return Optional.empty(); // 显式降级，不抛出
}
}
// 流中直接使用
List<Config> configs = keys.stream()
.map(YourUtil::safeLoadConfig)
.flatMap(Optional::stream)
.collect(Collectors.toList());
注意：Optional 不是万能解药
它解决的是“值是否存在”的问题，不是“操作是否成功”的问题。以下情况仍需传统异常处理：
- IO、网络、事务类操作失败（应抛受检异常或明确 RuntimeException）
- 业务规则校验失败（建议抛自定义业务异常，而非返回 empty Optional）
- 流操作本身抛出 UnsupportedOperationException 等运行时异常
Optional + Stream 的优雅降级，本质是把“空值场景”转化为函数式流程中的合法分支，让代码更贴近业务意图，而不是被防御性检查和异常捕获淹没。
