必须用optional.ofnullable而非of，因其能安全处理第三方接口常见的null返回（如feign超时、dubbo序列化失败等），将隐式空风险转为显式optional.empty()，强制通过orelse/orelsethrow/ifpresent等主动处理，支持链式判空与业务语义兜底，并可联动日志监控实现空值可观测。
直接用 Optional.ofNullable 包住第三方接口返回值，把“可能为空”这个事实显性化，逼你在后续链路中主动处理，而不是等 NPE 在半夜三点炸穿线上服务。
为什么必须是 ofNullable，不是 of
老旧三方接口返回 null 是常态：Feign 超时、Dubbo 序列化失败、XML 解析字段缺失、HTTP 204 响应体为空……这些都不是 bug，是现实。
Optional.of(null) 会当场抛 NPE，等于没防；ofNullable(null) 返回 Optional.empty()，不崩、不吵、留出处理空间。
- 它不改变接口行为，只帮你把“空”从隐式风险变成显式状态
- 它不自动兜底，但强制你写下
orElse、orElseThrow或ifPresent—— 每一次调用都在提醒：“这里可能没值”
嵌套对象判空一步到位
比如三方返回 Response<data></data>，而你要取 response.getData().getUser().getProfile().getAvatarUrl()，传统写法要套四层 if。
用 ofNullable 链式穿透：
String avatar = Optional.ofNullable(response)
.map(Response::getData)
.map(Data::getUser)
.map(User::getProfile)
.map(Profile::getAvatarUrl)
.orElse("default-avatar.png");
任意一环为 null，链自动中断，最后走默认值，不报错、不中断流程。
配合业务语义做精准兜底
空值不等于错误，而是业务信号。比如支付回调中 orderNo 为空，可能意味着“订单未创建成功”，该走补偿逻辑，不该直接返回 500。
用 orElseThrow 绑定领域异常：
String orderNo = Optional.ofNullable(callback.getOrderNo())
.filter(s -> !s.trim().isEmpty())
.orElseThrow(() -> new BusinessException("回调缺少有效订单号，需人工介入"));
既避免了空指针，又把技术空值翻译成可运维、可告警的业务问题。
和日志/监控联动，让空值可见可控
老旧接口空值频发，光防不住，还得看得见。可以在关键节点加轻量埋点：
Optional.ofNullable(thirdPartyClient.invoke())
.map(Result::getData)
.map(this::processData)
.or(() -> {
log.warn("三方接口返回空数据，traceId={}", MDC.get("traceId"));
metrics.counter("thirdparty.null.response").increment();
return Optional.empty();
});
空值不再静默丢失，而是进日志、进指标、进告警——下次复盘时，你知道是哪个接口、哪个字段、多高频在掉链子。
