使用Optional封装业务逻辑的核心是明确空值语义、将空值处理下沉至领域方法，如User::safeGetAddress()，避免上层重复判空；组合时优先flatMap，返回时按场景选orElse/orElseGet/orElseThrow，工具类封装通用失败操作。
用 Optional 封装复杂业务逻辑的返回结果，核心不是“加一层 Optional”，而是让空值语义清晰、处理下沉、调用简洁。重点在于设计意图明确：这个结果天然就可能不存在，而不是事后补救 null。
把空值判断收进领域方法里
别在 service 或 controller 里反复写 Optional.ofNullable(obj).map(...).flatMap(...)。应该在实体或领域对象中提供带语义的方法：
-
User::safeGetAddress() → Optional<Address>（不抛 NPE，也不返回 null） -
Order::latestValidPayment() → Optional<Payment>（已内置状态过滤和非空校验） -
Product::getEffectiveCategory() → Optional<Category>（自动跳过已下架或无分类的情况）
这样上层业务代码就能直接链式表达意图：order.latestValidPayment().map(Payment::getAmount).filter(a -> a.compareTo(BigDecimal.TEN) >= 0).isPresent()
组合多个 Optional 时优先用 flatMap 而非 get + if
当一个操作依赖前一步 Optional 的值，且该值本身也可能是空时，flatMap 是自然选择：
- ❌ 错误示范：
user.getAddress().getCity()—— 两层 null 风险 - ✅ 正确写法：
Optional.ofNullable(user).flatMap(User::getAddress).flatMap(Address::getCity) - 需要转换并保持 Optional 容器性时，
map适合纯值变换，flatMap适合返回另一个 Optional 的场景
返回结果时明确语义，慎用 orElseThrow
业务方法返回 Optional<T> 后，调用方应根据上下文决定如何收尾：
- 有合理默认值 → 用
orElse("北京") - 默认值计算开销大或需上下文 → 用
orElseGet(this::computeDefault) - 空值代表严重业务异常（如订单必须有收货地址才能发货）→ 才用
orElseThrow(() -> new MissingDeliveryAddressException())，且异常类型要具体
避免 orElseThrow(() -> new RuntimeException("xxx"))，这违背 Optional 的设计初衷，也掩盖了问题本质。
工具类封装通用转换逻辑
对常见“可能失败”的操作，封装成返回 Optional 的静态方法，复用性强：
-
Optional<Integer> parseInt(String s)：内部捕获NumberFormatException -
Optional<LocalDateTime> parseTime(String s)：统一处理格式错误 -
Optional<BigDecimal> safeDivide(BigDecimal a, BigDecimal b)：规避除零
这些方法可被配置读取、参数解析、外部接口适配等场景直接复用，不再散落各处 try-catch。
