面经策

Optional 的正确使用姿势是什么？哪些场景不该用？ ​

  • 标签：Java、新特性

🏛 业务架构师 ​

Optional 的正确使用姿势与禁忌，我按"定位—正解—误用"讲：

定位：Optional 是返回值的表达工具——向调用方声明"这个方法可能没有结果"，替代返回 null（调用方忘判空就 NPE）与"魔法值"（返回 -1、空串）。

正确姿势：

  1. 返回类型用它：查找类方法 Optional<Order> findById(String id)——强迫调用方面对"可能没有"；
  2. 链式消费：order.map(Order::getUser).map(User::getEmail).orElse("unknown")——替代层层判空金字塔；
  3. 组合语义清晰：orElseThrow(() -> new BizException("订单不存在"))——把"没有"显式转为业务异常；orElse / orElseGet（惰性求值，有副作用成本时用 Get 版）；
  4. **作为方法参数接收"可缺省"**也可以（但重载/默认值往往更清晰）。

不该用的场景：

  1. 字段不用：实体/DTO 的成员变量用 Optional 增加内存开销、序列化兼容问题、且字段可空性应由校验/类型表达；
  2. getter 不用：同上，接口层面暴露 Optional 字段是坏味道；
  3. 集合不用：返回 Optional<List<T>> 是反模式——空集合天然表达"没有"，直接返回 List.of()；
  4. 构造参数/Map 的 value 不用：语义混乱；
  5. 别用 isPresent()+get() 组合——那就是换了皮的 null 检查，用 map/ifPresent/orElse 表达意图。

业务价值：Optional 把"空值风险"从运行时异常提前到类型契约层——接口读起来就知道"可能没有"，新人接手少踩 NPE。这是用轻微的代码仪式感换系统级健壮性的划算交易，但前提是用对场景。

🏗 系统架构师 ​

Optional 的正确姿势 = "可能缺席的返回值"的类型化表达，我按"该用/不该用"划界：

该用：

  • 返回值：查询可能无结果时返回 Optional<User>——把"可能没有"编码进类型签名，调用方不可能忘记检查（编译器盯着）；替代返回 null（调用方裸奔）或抛异常（控制流滥用）；
  • 链式导航：user.map(User::getAddress).map(Address::getCity).orElse("unknown")——多层 null 检查的声明式替代；
  • 组合 API：orElse/orElseGet/orElseThrow/ifPresent/ifPresentOrElse/filter/flatMap 按语义选——orElseGet 惰性求值（默认值昂贵时），orElse 参数总会求值（副作用陷阱）。

不该用（架构纪律）：

  • 字段不用：Optional 非序列化、字段语义模糊——字段可空性用 @Nullable 注解表达；
  • 参数不用：方法参数要求 Optional 徒增调用方负担，重载或默认参数更清晰；
  • 集合不用：Optional<List<T>> 反模式——空集合天然表达"无元素"，直接返回 List.of()；
  • get() 禁用：opt.get() 不检查就取 = 比裸 null 更嚣张——要值用 orElseThrow（带消息）；
  • isPresent()+get() 组合禁用：这等于 null 检查换皮，用 map/ifPresent；
  • 构造用 Optional.ofNullable(x) 包第三方可能返回 null 的边界值——Optional 是边界处对 null 的收口。

一句话：Optional 是"用类型系统传播缺席语义"的工具——只在出口（返回值）和边界（吸收外部 null）使用，别让它渗透领域模型。

💻 全栈开发专家 ​

Optional 的正确姿势，我按「该用/不该用/怎么用」划线：

该用：

  1. 返回值：方法可能「没有结果」时——Optional<User> findById(Long id)，逼调用方面对空值分支；
  2. 链式取值：user.map(User::getDept).map(Dept::getName).orElse("未知")——干掉嵌套 if-null；
  3. 与 Stream/flatMap 组合处理可空数据。

核心 API 心法（实战排列）：

java
opt.filter(Objects::nonNull)      // 链中过滤
   .map(User::getEmail)
   .or(() -> Optional.of(fallback))   // or：备选 Optional（JDK 9）
   .ifPresentOrElse(this::send,      // 双分支
                    () -> log.warn("无邮箱"));
User u = opt.orElseThrow(() -> new BizException("用户不存在"));
// orElse vs orElseGet：orElse(兜底) 总是求值（有副作用/开销时用 orElseGet 惰性）

不该用：

  1. 字段/方法参数——Optional 非可序列化、字段多一层包装得不偿失；参数要可空宁可重载或 @Nullable 注解；
  2. 集合返回：空集合直接返回 List.of()，别 Optional<List>；
  3. get() 裸调用：不判 isPresent 就 get 等于把 NPE 换成 NoSuchElementException——review 必拦；
  4. 链条中间过度包装（每层都 Optional.ofNullable 再拆）——可空源头一次包装，链内传递保持 Optional。

框架现实：JPA/Spring Data 的返回值 Optional 已成标准（findById）；MyBatis-Plus 2.x 也支持。团队规约可以一句话总结：返回值可空就 Optional，其他地方（字段/参数/集合/数组）一律不用，orElseThrow 优先于 orElse(null)。