Stream.count()不支持过滤，必须配合filter()使用；正确写法为stream.filter(...).count()，返回long类型，需注意遍历成本、溢出风险及不可复用性。
Stream.count() 本身不支持过滤，必须配合 filter()
Stream.count() 是一个终端操作，它只统计当前流中剩余元素的总数，不会自动应用任何条件。想统计“符合过滤条件”的数量，必须先用 filter() 筛选，再调用 count()。直接在未过滤的流上调用 count() 得到的是全量计数。
正确写法：filter + count 组合链式调用
典型模式是 stream.filter(...).count()，返回值类型为 long（不是 int），这是设计使然——流可能极大，int 容易溢出。
示例：
long activeUsers = users.stream()
.filter(user -> user.isActive())
.count();
注意点：
-
filter()的参数是Predicate<T>，必须返回boolean -
count()之后流已关闭，不能再复用或继续调用其他终端操作 - 若源集合为空或所有元素被
filter排除，结果为0L（不是null）
常见错误：误用 map 或提前终止导致计数异常
以下写法看似简洁，实则危险：
// ❌ 错误：map 后流中元素变成 Boolean，count() 统计的是 Boolean 对象个数，不是 true 个数 long count = list.stream().map(x -> x > 5).count(); // ✅ 正确：filter 保留原始元素，只留下满足条件的 long count = list.stream().filter(x -> x > 5).count();
其他易错场景：
- 在
filter中抛出异常（如空指针）会导致整个count()失败 - 对并行流（
parallelStream()）使用有状态的filter（如依赖外部计数器）会引发不可预测结果 - 误以为
count()是中间操作，试图链式接map—— 编译直接报错，因为count()返回long，不是Stream
性能与替代方案：大数据量时需谨慎
count() 是短路操作吗？不是。count() 必须遍历全部匹配元素（哪怕只是计数），无法跳过后续处理。这意味着：
- 对于超大流（如千万级日志行），即使只想要“是否大于 0”，
filter(...).count() > 0仍会全量扫描 - 此时应改用
anyMatch()（存在性判断）或findFirst()（取第一个）来提前终止 -
count()在并行流中需合并各分段计数，有额外开销；单线程流反而更轻量
真正需要精确总数时，filter().count() 是最直白可靠的方案，但得清楚它隐含的遍历成本。
别忽略 count() 返回的是 long —— 如果你把它赋给 int 变量又不做检查，溢出时不会报错，只会静默截断。
