核心目标是切断空值向下游传播路径，避免NPE连锁崩溃；应在业务门面层用Optional.ofNullable封装Feign返回值，配合ResponseEntity明确HTTP空语义，解包须用orElseGet，禁用于API返回、序列化与持久化。

用 Optional.ofNullable 封装 RPC 接口返回值，核心目标不是“防止雪崩”，而是**切断空值向下游传播的路径，避免因一次 null 引发多层 NPE 连锁崩溃**。它本身不解决超时、熔断、限流等雪崩成因，但能显著提升空值场景下的容错清晰度和调用链稳定性。

只在业务门面层封装，不在 Feign 接口签名中暴露 Optional

Feign 默认不识别 Optional<user></user>，强行声明会导致解码失败或 HTTP 500。正确做法是：

• Feign 客户端方法保持返回原始类型，例如 User getUserById(Long id)
• 在上层服务门面（如 UserFacade）中统一包装：return Optional.ofNullable(feignClient.getUserById(id));
• 门面方法命名体现语义，例如叫 findUserById 而非 getUserById，暗示“可能为空”

配合 ResponseEntity 明确 HTTP 空状态语义

当远程服务约定 “404 表示资源不存在”，应让 Feign 返回 ResponseEntity<user></user>：

• 成功响应（200）→ ResponseEntity.of(Optional.of(user))
• 空响应（204 或 404）→ ResponseEntity.notFound().build()
• 门面层再转为 Optional.ofNullable(responseEntity.getBody())，既保留 HTTP 语义，又统一空值处理口径

解包必须用 orElseGet，禁用 orElse 做重操作

避免在默认值计算中引入新风险点：

• ❌ 错误： optional.orElse(dbFallbackService.loadDefaultUser()) —— 每次都执行 DB 查询
• ✅ 正确： optional.orElseGet(() -> dbFallbackService.loadDefaultUser()) —— 仅在 optional 为空时才触发
• 若 fallback 成本仍高（如远程调用），应直接抛出业务异常或返回兜底空对象，而非掩盖问题

不用于 public API，也不参与序列化与持久化

Optional 是运行时容器，不是数据载体：

• Controller 层不要返回 Optional<string></string>，前端收不到有效 JSON，会报 500 或空对象
• MyBatis 的 @Select 方法别声明返回 Optional<order></order>，映射器无法识别，结果恒为 null
• 日志、MQ 消息、DB 字段中禁止存 Optional 实例——它没有序列化契约，也不该跨边界