Java Stream API中分区与归并的核心是声明式实现“二分”与“聚合”：partitioningBy按布尔条件精准二分，返回true/false键的Map；reduce逐元素累积归约为单值；collect配合自定义Collector支持多指标结构化归并；groupingBy适用于多类别分组，partitioningBy为其布尔特例，语义更聚焦、性能略优。
Java Stream API 中的数据分区与归并，核心在于用声明式方式完成“二分”与“聚合”两类关键操作——分区强调按布尔条件切分数据，归并侧重将流中元素逐步合并为单一结果或结构化容器。
partitioningBy：精准二分，适合真假判定场景
Collectors.partitioningBy 接收一个 Predicate，自动把流拆成 true 和 false 两个键对应的子集。它不关心分组键的语义，只认布尔结果，因此天然适配启用/禁用、合格/不合格、奇数/偶数等非此即彼的业务判断。
- 基础用法直接返回 Map<Boolean, List<T>>，例如按订单是否含有效商品 ID 分区：
.collect(Collectors.partitioningBy(order -> order.getItems().stream().allMatch(item -> item.getSkuId() != null))) - 第二个参数可嵌套任意收集器，实现“分区+汇总”一步到位：用 summingInt 算各组数值和，用 counting() 统计数量，用 toSet() 去重后保留集合结构
- 注意返回 Map 的 key 固定为 true/false，不能自定义；若需多分类（如按状态分三类），应改用 groupingBy
reduce：从元素到单值的累积归约
reduce 是最底层的归并原语，适用于需要将流中所有元素逐步合并为一个结果的场景，比如求和、拼接、找最大值。它有三种常见重载形式，区别在于是否提供初始值及如何合并。
- 无初值版本（T reduce(BinaryOperator<T>)）要求流非空，否则抛 NoSuchElementException；适合自然存在“单位元”的运算，如整数加法（0 是单位元），但字符串拼接就不安全
- 有初值版本（T reduce(T identity, BinaryOperator<T>)）更常用：identity 作为起点，每轮用 operator 合并当前累加结果与下一个元素
- 并行友好版（U reduce(U identity, BiFunction<U,? super T,U>, BinaryOperator<U>)）显式分离“累加器初始化”“元素加入”“结果合并”，适合复杂对象归并，比如用 StringBuilder 拼接并确保线程安全
collect + 自定义 Collector：灵活可控的结构化归并
当 reduce 表达力不够（如需同时统计总数、平均值、去重集合），collect 配合自定义 Collector 是更清晰的选择。它把归并过程明确拆解为四步：supplier（准备容器）、accumulator（加元素）、combiner（合并中间结果）、finisher（产出终值）。
立即学习“Java免费学习笔记（深入）”；
- 用 Collector.of 快速组装，避免写冗长接口实现；例如构建 TopK 收集器，累加器直接用 PriorityQueue，插入即维护堆序
- 累加器类型尽量轻量：计数用 int[1] 或 AtomicInteger，避免频繁装箱；分组统计用 Map<K, double[]> 存 sum/count/min/max 多指标
- 若 finisher 不做转换（如返回原 ArrayList），加上 Characteristics.IDENTITY_FINISH 可跳过额外包装，提升性能
groupingBy 与 partitioningBy 的分工边界
两者都生成 Map，但设计目标不同：groupingBy 按任意分类函数（返回任意类型 K）分组，适合多类别聚合；partitioningBy 是 groupingBy 的特例，仅支持布尔分类，内部做了优化，性能略高且语义更聚焦。
- 当你需要“是/否”“通过/未通过”“在线/离线”这类明确二分时，优先选 partitioningBy —— 代码更直白，意图更清晰
- 如果后续要扩展为“待审核/已通过/已拒绝/已取消”等多状态，立刻切换到 groupingBy，避免后期重构
- 两者都支持嵌套下游收集器，比如 groupingBy(classifier, counting()) 或 partitioningBy(pred, summingDouble(...))，组合能力一致
