Optional 应仅用于语义上可能为空的外部 API 返回值，如查单条数据或配置项；在 HTTP 客户端层立即封装，配合超时、断路器、降级形成统一防护出口，禁止裸调 get() 或判空回退。
直接用 Optional 封装外部 API 返回值，不是为了“加一层壳”，而是把“调用可能失败”这个事实，从隐式约定变成显式契约。它本身不防系统崩溃，但配合超时、断路器、降级等机制，能切断外部故障向内传导的路径。
只对“语义上可能为空”的返回值用 Optional
不是所有外部调用都要套 Optional。关键看方法语义：
- 查单条数据（如
getProductById(Long id)）→ 合理。产品可能下架或 ID 不存在，结果天然可空，返回Optional<product></product>明确告知调用方“你得处理查不到的情况” - 执行动作（如
sendSms(String phone, String msg)）→ 不合理。这个操作要么成功要么抛异常，返回Optional<boolean></boolean>没意义，应直接返回void或抛SmsSendException - 配置类接口（如
getConfigValue(String key)）→ 合理。key 可能未配置，返回Optional<string></string>比返回null更清晰
封装时机：在最外层 HTTP 客户端之后立即包装
不要等到 Service 层才包，要在拿到原始响应后第一时间封装。例如用 RestTemplate 调用支付服务：
public Optional<PaymentResult> callPaymentApi(PaymentRequest req) {
try {
// 设置超时，避免线程卡死
HttpEntity<PaymentRequest> entity = new HttpEntity<>(req, headers);
ResponseEntity<PaymentResult> response = restTemplate.exchange(
paymentUrl, HttpMethod.POST, entity, PaymentResult.class
);
// 成功响应且 body 非 null 才封装
return Optional.ofNullable(response.getBody());
} catch (ResourceAccessException | HttpClientErrorException e) {
// 网络失败或 4xx 错误 → 视为“无结果”，不抛异常
log.warn("支付API调用失败: {}", e.getMessage());
return Optional.empty();
} catch (Exception e) {
// 其他异常（如反序列化失败）按需处理，一般也返回 empty
log.error("支付API解析异常", e);
return Optional.empty();
}
}
这样就把网络层的不确定性（超时、连接拒绝、HTTP 错误码、JSON 解析失败）全部收敛为一个 Optional，上层无需关心底层是哪种失败。
链式处理 + 明确降级，避免 get() 和 null 回退
调用方拿到 Optional<paymentresult></paymentresult> 后，必须用声明式方式处理，而不是解包再判空：
- ✅ 有默认逻辑：用
orElseGet()延迟加载备选方案，比如查本地缓存或走离线流程 - ✅ 必须存在才继续：用
orElseThrow(() -> new ExternalServiceUnavailableException("支付服务不可用"))，错误信息比get()抛的NoSuchElementException有用得多 - ✅ 需要转换再判断：用
map(r -> r.getStatus()).filter("SUCCESS"::equals).isPresent()，不暴露中间 null - ❌ 禁止裸调
.get()，等于放弃 Optional 的保护价值 - ❌ 禁止写
optional == null ? ... : optional.get()，这和没用 Optional 一样脆弱
与断路器、超时联动，形成完整防护
Optional 是“表达层”，真正扛住冲击靠的是基础设施：
- 超时控制：HTTP 客户端必须设
connectTimeout和readTimeout（如各 2 秒），防止线程被拖死 - 断路器（如 Resilience4j）：连续失败 5 次后自动熔断，后续请求直接返回
Optional.empty()，不发网络请求 - 线程隔离：外部调用放在独立线程池（如 Hystrix 的 command thread pool 或 Resilience4j 的 ThreadPoolBulkhead），避免拖垮主业务线程
- 兜底降级：熔断或超时时，
orElseGet()可触发短信通知运营、记录异步任务、返回预设静态页等
此时 Optional 就成了整个防护链路的“统一出口类型”，上游不管底层是熔断、超时还是 HTTP 404，看到的都是同一个语义清晰的容器。
