Collectors.counting() 是返回 Long 的静态收集器，必须配合 collect() 使用，适用于分组或复合聚合场景；而 stream.count() 是直接返回 long 的终端操作，适合简单总数统计。
Collectors.counting() 是 Java Stream 中最轻量、最直接的计数工具，但它不是万能的——它只返回 long，且必须配合 collect() 使用，不能单独调用。
为什么不能直接写 list.stream().counting()？
因为 counting() 是一个静态工厂方法，返回的是 Collector，它本身不是操作函数，不能被流“调用”。常见错误是把它和 count()（终端操作）混淆。
-
stream.count()是终端操作，直接返回long，适合简单总数统计 -
Collectors.counting()是收集器，必须用于collect()，常用于分组后计数（如groupingBy(..., counting())） - 误写成
stream.collect(counting)但没加括号()会导致编译失败：找不到符号
什么时候必须用 Collectors.counting() 而不是 stream.count()？
当你需要在聚合过程中嵌入计数逻辑，尤其是和 groupingBy 或 partitioningBy 配合时。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 按城市分组并统计人数：
map.entrySet().stream().collect(groupingBy(e -> e.getKey(), counting())) - 统计偶数个数的同时保留原始流做其他处理（需复用流时，
count()会消费流，而counting()可放在复合 collector 中） - 与
mapping()组合，例如只对非 null 元素计数：collect(mapping(e -> e != null ? 1 : null, filtering(Objects::nonNull, counting())))（注意：Java 16+ 才支持filtering）
性能和类型陷阱：Long vs int，以及空指针风险
counting() 总是返回 Long，即使数据量很小。若你明确知道元素数不会超 Integer.MAX_VALUE，又想存进 int 字段，得手动强转——但别忽略溢出可能。
- 下游接收类型不匹配：比如
Map接groupingBy(key, counting())会编译失败，必须用Map - 空流没问题：
Stream.empty().collect(counting())安全返回0L - 如果源是
Optional或含 null 的集合，counting()本身不判空，但流构造阶段可能抛NullPointerException（例如list.stream()中list为 null）
真正容易被忽略的是场景错配：想快速知道列表长度，却去写 list.stream().collect(counting())——这比 list.size() 或 stream.count() 多绕一层，还触发了 Collector 的中间状态管理。只有当计数是更大收集逻辑的一环时，counting() 才体现出价值。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
