optional.flatmap() 能扁平化嵌套调用，因为它接收返回optional的函数并自动展开一层，避免map().map()冗余堆叠；它强制每步返回optional，天然防止多层包装，但仅适用于单值可选链，不处理list或completablefuture。
为什么 Optional.flatMap() 能扁平化嵌套调用
因为 flatMap() 的设计就是「接收一个返回 Optional 的函数，并自动展开一层」——它不把 Optional<optional>></optional> 当作合法返回值，而是强制你提供 Optional<t></t>，从而天然阻止多层 .map().map().map() 堆叠。
常见错误是误用 map()：比如对 user.getAddress().getCity() 这类链式调用做保护，写成 optionalUser.map(u -> u.getAddress()).map(a -> a.getCity())，结果一旦 getAddress() 返回 null 或空 Optional，第二层 map() 就会作用在 Optional.empty() 上，继续返回 Optional.empty() ——逻辑没错，但结构仍显冗余；而用 flatMap() 可以把“取地址”和“取城市”合并为一步语义。
-
map()：适用于返回普通值（如String、Integer）的函数，结果被包进新Optional -
flatMap()：适用于返回Optional的函数（如getUser().getAddress()本身可能返回Optional<address></address>），结果直接展开，不嵌套 - 如果函数返回的是
null而非Optional，必须先用Optional.ofNullable()包装，否则flatMap()会抛NullPointerException
怎么把三层 null 安全调用转成一行 flatMap() 链
假设模型是 User → Optional<address> → Optional<string> city</string>
</address>，且每个环节都可能为空。不能直接链式调用 user.getAddress().getCity()，但也不该写三层 ifPresent 或嵌套 map()。
正确做法是让每一步都返回 Optional，再用 flatMap() 串联：
Optional<string> city = optionalUser
.flatMap(u -> Optional.ofNullable(u.getAddress()))
.flatMap(a -> Optional.ofNullable(a.getCity()));</string>
注意两点：
- 不能写
u.getAddress().getCity()在 lambda 里——那又回到原始 null 风险；必须拆开，每步单独判空并包装 - 如果
getAddress()已经返回Optional<address></address>（推荐接口设计），就直接.flatMap(User::getAddress)，无需ofNullable() - 性能无额外开销：
flatMap()内部只是判断是否为空，没有创建中间对象
flatMap() 和 map() 混用时最容易踩的坑
最典型错误：在 flatMap() 后跟了一个返回非 Optional 的 map()，以为能继续链式处理，结果发现类型对不上。
例如：
optionalUser
.flatMap(u -> u.getAddress()) // 返回 Optional<address>
.map(a -> a.getCity().toUpperCase()); // ✅ 正确：map 处理 String</address>
但下面这段就错了：
optionalUser
.flatMap(u -> u.getAddress())
.flatMap(a -> a.getCity()); // ❌ 编译失败：a.getCity() 是 String，不是 Optional<string></string>
修复方式只有两个：
- 改用
map()：如果后续操作不产生新Optional - 补上包装：如
a.getCity() != null ? Optional.of(a.getCity().toUpperCase()) : Optional.empty()，但通常说明设计已偏离简洁初衷 - 更隐蔽的坑：lambda 中调用了可能抛异常的方法（如
parseDouble），flatMap()不捕获异常，需在外层 try 或提前验证
当嵌套里混入集合或异步操作时，flatMap() 还管用吗
不管用——Optional.flatMap() 只解决「单值可选链」问题，不处理 List 或 CompletableFuture。比如你想从 User 拿到所有订单的城市列表，写成：
optionalUser
.flatMap(u -> u.getOrders()) // ❌ getOrders() 返回 List<order>，不是 Optional</order>
这时要么转换思路（用 stream() + flatMap() 配合 Optional.stream()），要么换工具：
- 对集合：先
.map(User::getOrders).orElse(Collections.emptyList())，再流式处理 - 对
CompletableFuture<optional>></optional>：需要用thenCompose()，不是Optional.flatMap() - 真正复杂的嵌套建议用 Vavr 的
Option或自定义 DSL，Java 原生Optional的定位就是轻量空值防护，不是全能流程控制
别指望靠一层 flatMap() 消灭所有嵌套——它只消灭一层「可选性」，不是消灭所有间接引用。
