flatMap 为什么比 map + 遍历更合适
因为 flatMap 的设计目标就是“把每个元素映射成一个流，再把所有流连成一个流”，天然适配嵌套集合的扁平化。用 map 只能返回 List<list>></list>，还得手动遍历合并；而 flatMap 一步到位，避免中间集合对象的创建开销。
常见错误现象：map 后直接 collect(Collectors.toList())，结果得到的是 List<list>></list>，不是想要的 List<string></string>。
- 适用场景：处理
List<list>></list>、List<optional>></optional>、List<stream>></stream>等“容器中装容器”的结构 -
flatMap接收的是Function super T, ? extends Stream extends R>>，必须返回Stream，不能返回List或Collection - 性能影响：若内部集合很大，
flatMap是懒求值，但最终collect时仍会全部加载进内存；频繁调用stream()本身开销极小，可忽略
处理 List> 的标准写法
这是最典型的扁平化需求，比如从多个用户获取其标签列表，最后要汇总成单层标签流。
List<List<String>> nested = Arrays.asList(
Arrays.asList("java", "stream"),
Arrays.asList("flat", "map"),
Collections.emptyList()
);
List<String> flat = nested.stream()
.flatMap(list -> list.stream()) // 关键：每个子 List 转成 Stream
.collect(Collectors.toList());
容易踩的坑：
立即学习“Java免费学习笔记（深入）”；
- 漏掉空集合防护：如果子列表可能是
null，list.stream()会 NPE；应先filter(Objects::nonNull) - 误写成
.flatMap(list -> Stream.of(list))：这会把每个List当作一个元素塞进去，结果是List<list>></list>，不是扁平的 - 类型推导失败：当子集合泛型不一致（如
List<object></object>和List<string></string>混用），编译器可能报错，需显式声明类型或统一上游
flatMap 处理 Optional 或数组的等效变体
flatMap 不只用于嵌套集合，也常用于解包 Optional 或展开数组——本质都是“一转多”逻辑的统一抽象。
常见错误现象：对 Optional 用 map 后得到 Optional<optional>></optional>，没意识到该用 flatMap。
- 解包
Optional：user.getProfile().flatMap(Profile::getAvatarUrl)，避免两层Optional - 展开数组：
Arrays.stream(strings).flatMap(s -> Arrays.stream(s.split(",")))，注意split可能返回空数组，不会出错但产生空元素 - 兼容性提示：Java 8+ 全支持；Android 上若用 desugaring，
flatMap无额外限制
嵌套层级加深时别硬套 flatMap
遇到 List<list>>></list> 这类三层结构，强行用 flatMap(flatMap(...)) 会让代码难读且易错。这不是 flatMap 的设计场景。
真实开发中更常见的做法是：提前规整数据结构，或用递归工具方法封装。硬拼三层 flatMap 容易漏掉某层的空校验，运行时才暴露 NullPointerException。
容易被忽略的地方：扁平化操作本身不改变元素顺序（前提是子流顺序稳定），但如果你在 flatMap 内部做排序或并行处理，顺序就不可控了——这点在分页或日志聚合场景里很关键。
