Optional 类是为可选语义明确、调用链清晰、空值需主动处理的场景提供类型安全表达，而非替代所有 null 判断；它将“可能无结果”从隐式风险转为显式契约。

Optional 类不是用来替代所有 null 判断的工具，而是为可选语义明确、调用链清晰、空值需主动处理的场景提供类型安全的表达方式。在复杂业务逻辑中，它真正发挥作用的地方，是把“可能没有结果”这件事从隐式风险变成显式契约。

用 map/flatMap 实现多层对象安全导航

当业务需要从嵌套对象中提取字段（比如用户→订单→优惠券→折扣金额），传统写法要层层判空，极易漏掉某一层。Optional 配合函数式操作能自然收敛空值路径：

• map 用于单层转换：比如 optUser.map(User::getProfile).map(Profile::getAvatarUrl)，任一环节为空，整个链返回空 Optional
• flatMap 用于嵌套 Optional：如果 User::getOrder 返回的是 Optional，就必须用 flatMap，否则会得到 Optional>，无法继续链式调用
• 典型组合：Optional.ofNullable(user).flatMap(u -> u.getOrder()).flatMap(o -> o.getCoupon()).map(c -> c.getDiscount())

用 filter + orElseThrow 实现条件拦截与异常分流

在审批、风控等流程中，“存在但不满足条件”和“根本不存在”往往需要不同响应。Optional 的 filter 可以把校验逻辑内聚进数据流：

• userRepository.findById(id).filter(User::isActive).orElseThrow(() -> new UserDisabledException()) —— 找到用户但已停用，抛定制异常
• configProperties.getTimeout().filter(t -> t > 0 && t —— 配置值存在但超出合理范围，自动降级为默认值
• 避免把“空”和“非法”混在同一 if 分支里处理，职责更清晰

用 orElse / orElseGet 做轻量级兜底与延迟计算

兜底不是简单填个默认值，而是要区分场景：静态默认值用 orElse，动态生成或开销较大时用 orElseGet（后者只在空时执行）：

• order.getAmount().orElse(BigDecimal.ZERO) —— 直接返回常量，无副作用
• cache.get(key).orElseGet(() -> fetchFromDB(key)) —— 仅当缓存未命中才查库，避免无谓远程调用
• 注意：orElse(new ExpensiveObject()) 即使 Optional 不为空也会创建实例，易引发性能问题

在 Controller 和 Service 层做语义分界

Optional 应该作为内部协作的“协议”，而不是暴露给外部的 API 类型：

• Controller 接收参数时可用 @RequestParam Optional keyword，表示该参数可选，再由 service 决定是否忽略或报错
• Service 方法返回 Optional 是合理的，表明“查不到结果”是合法业务状态；但不要让 DTO 或响应体字段声明为 Optional，JSON 序列化会出问题
• 对外接口统一返回标准结果包装类（如 Result），内部用 Optional 编排逻辑，保持边界干净