关于java.util.Optional类设计决策的技术疑问

1. 为什么允许嵌套Optional，且不会自动展开？ #

Java是静态强类型语言，Optional.of(T)的泛型参数T严格遵循传入的参数类型。当你传入Optional<String>时，T就是Optional<String>，结果必然是Optional<Optional<String>>——这是类型系统一致性的要求，自动展开反而会破坏类型的明确性，让开发者无法预期实际的类型结构。

嵌套Optional并非无意义，存在不少合理场景：

• 调用可能失败的远程查询接口：外层Optional表示“是否成功获取到查询结果”，内层Optional表示“查询结果里是否有目标数据”，比如Optional<Optional<Order>>可以区分“服务调用失败”和“服务调用成功但无订单”两种不同的空值场景。
• 处理多层可选配置：比如从配置文件读取可选的数据库配置，而数据库配置中的密码又是可选项，此时Optional<Optional<String>>能明确区分“配置不存在”和“配置存在但未设置密码”。

2. 为什么不重载map替代flatMap？ #

首先是泛型擦除导致的重载冲突：Java泛型编译后会被擦除，你设想的两个map方法，擦除后的参数都会变成Function，这会导致方法签名重复，编译无法通过。

其次是语义清晰性的要求：在函数式编程惯例中，map和flatMap的职责明确分离——map负责转换Optional内的值，保留包装结构；flatMap负责将值转换为另一个Optional并自动扁平化（避免嵌套）。如果合并成一个方法，开发者需要额外理解“方法会根据返回值自动切换逻辑”，反而增加认知成本，不符合API设计的“最小惊讶原则”。

3. 为什么保留抛出异常的get()方法，还有orElseThrow()？ #

get()的存在有几个核心原因：

• 历史兼容：Optional在Java 8推出时，需要兼顾部分开发者的使用习惯，允许在已经确定Optional有值的场景下（比如提前用isPresent()判断过）快速获取值。
• 语义明确：get()是显式的不安全操作，用来提醒开发者：“如果你不确定有值就调用我，会抛出异常”，这比直接返回null更直观——至少异常会明确告诉你“空值被访问了”，而非隐藏在后续代码中引发难以排查的空指针。

orElseThrow()是get()的增强版，允许开发者自定义抛出的异常类型，更灵活适配业务场景。两者定位不同：get()适合已确认非空的场景（代码更简洁），orElseThrow()适合需要自定义异常信息的场景。

内容的提问来源于stack exchange，提问作者zombieParrot