Collectors.groupingBy需配合下游收集器才能实现SQL的GROUP BY+聚合功能；其核心是二参数重载groupingBy(Function, Collector)，前者指定分组键，后者定义每组统计逻辑，如counting()、summingInt()等。
Collectors.groupingBy 能实现 SQL 的 GROUP BY + 聚合，但默认只做分组映射，不带求和、计数等统计；要真正对标 SQL，必须配合下游收集器（downstream collector）。
groupingBy 的基本结构：三个参数怎么填
最常用的重载是 groupingBy(Function, Collector)，其中：
-
Function对应 SQL 的GROUP BY字段，比如Person::getDepartment - 第二个参数是下游收集器，决定“每组内做什么”，比如
Collectors.counting()对应COUNT(*)，Collectors.summingInt(Person::getSalary)对应SUM(salary) - 三参数版本
groupingBy(keyMapper, supplier, downstream)仅在需要自定义 Map 实现（如TreeMap）时才用，日常几乎不用
常见 SQL 场景对应写法
假设有一个 List<person></person>，字段含 department、salary、age：
-
SELECT department, COUNT(*) FROM person GROUP BY department→Collectors.groupingBy(Person::getDepartment, Collectors.counting()) -
SELECT department, AVG(salary) FROM person GROUP BY department→Collectors.groupingBy(Person::getDepartment, Collectors.averagingDouble(Person::getSalary)) -
SELECT department, MAX(age), MIN(age) FROM person GROUP BY department→ 用Collectors.collectingAndThen(Collectors.maxBy(Comparator.comparing(Person::getAge)), opt -> opt.map(Person::getAge).orElse(null))，但更推荐先用groupingBy分组再遍历计算，避免嵌套过深
容易踩的空指针和类型陷阱
下游收集器对 null 值敏感：
-
summingInt和averagingInt遇到null字段会抛NullPointerException，务必提前过滤或用Objects.nonNull判断 - 如果分组键可能为
null（如person.getDepartment()返回 null），groupingBy默认把它们归入 key 为null的组——这没问题，但后续处理时容易漏掉这个分支 - 返回类型是
Map<k d></k>，其中D是下游收集结果类型；比如用counting()得到Map<string long></string>，别误当成Integer
性能与可读性权衡：什么时候不该硬套 groupingBy
单次分组+简单聚合用 groupingBy 清晰直接；但遇到多指标、条件聚合（如 SQL 的 CASE WHEN）或需中间状态时，强行塞进下游收集器会让代码难懂且难调试：
- 例如 “每个部门的高薪人数（salary > 15000）和总薪资” —— 推荐先
stream().collect(Collectors.groupingBy(Person::getDepartment))得到Map<string list>></string>，再对每个List手动遍历统计 -
groupingBy是一次性终态操作，无法像 SQL 那样链式叠加多个HAVING或ORDER BY；排序需额外调用new TreeMap(result)或result.entrySet().stream().sorted(...)
分组逻辑越复杂，越容易在下游收集器里堆砌嵌套，最后连自己都看不懂返回值类型是怎么推导出来的。
