Stream.peek() 不改变流内容，适合在中间步骤（如filter后）统计通过元素数，但需配合终端操作、用AtomicLong等线程安全变量，且终端操作不能是短路的。
Stream.peek() 本身不改变流内容，但统计数量需要额外变量
peek() 的设计目的就是“观察”流中每个元素，执行副作用操作而不影响流的结构或内容。它不会过滤、映射或终止流，所以适合插入统计逻辑。但注意：peek() 是惰性求值的——只有流真正被终端操作（如 count()、collect()、forEach()）驱动时，里面的 lambda 才会执行。如果流没被消费，peek() 里的计数器根本不会动。
常见错误是直接写：
long count = 0; stream.peek(e -> count++); // ❌ 这里 count 永远是 0，流没触发
正确做法是确保后续有终端操作，且计数变量必须是有效作用域内的可修改引用：
- 用
AtomicLong或数组（如long[] count = {0}）绕过“局部变量需为 final”的限制 - 避免在多个线程并行流（
parallelStream()）中用普通long，否则结果不可靠 - 如果只是要总数，优先考虑
count()；peek()统计只适用于“想在某个中间步骤（比如 filter 后、map 前）精确知道有多少元素通过了”的场景
在 filter 后用 peek() 统计实际进入下游的元素数
这是最典型的需求：你想知道 filter() 留下了多少元素，又不想打断流链式调用。此时 peek() 插在 filter() 之后、其他操作之前，是最自然的位置。
示例：统计字符串流中长度 > 3 的元素个数，并继续转成大写
AtomicLong passed = new AtomicLong(0);
List<String> result = Stream.of("a", "hello", "hi", "world")
.filter(s -> s.length() > 3)
.peek(s -> passed.incrementAndGet()) // ✅ 此时 s 已通过 filter
.map(String::toUpperCase)
.collect(Collectors.toList());
System.out.println("filter 后通过数：" + passed.get()); // 输出 2
关键点：
- 不能把
peek()放在filter()前，否则统计的是原始数量 - 如果流是并行的，
AtomicLong是安全的；用long[]也行，但原子性得自己保证（通常够用） - 不要在
peek()里做耗时或阻塞操作，会拖慢整个流处理
为什么不用 collect(Collectors.counting()) 替代 peek()？
collect(Collectors.counting()) 是终端操作，一调用流就结束了，无法继续链式处理。而 peek() 是中间操作，可以无缝嵌入流管道中。
对比：
// ❌ 错误：count() 终止流，后面 map 不会执行 long n = stream.filter(...).count(); stream.map(...); // 这个 stream 已关闭，抛 IllegalStateException // ✅ 正确：peek() 不终止，流继续流动 AtomicLong c = new AtomicLong(); List<R> result = stream.filter(...).peek(x -> c.incrementAndGet()).map(...).collect(...);
所以，是否用 peek() 统计，本质是在问：“我还需要这个流后续做什么？” 如果只需要总数，用 count() 更简洁；如果还要接着处理，peek() 是唯一能兼顾“观察+通行”的选择。
容易被忽略的陷阱：peek() 在短路操作下可能不执行全部元素
peek() 的执行次数取决于终端操作是否短路。比如 findFirst()、anyMatch() 只处理到满足条件的第一个元素就停止，后面的 peek() 根本不会触发。
示例：
AtomicLong seen = new AtomicLong(0);
Optional<String> opt = Stream.of("a", "bb", "ccc", "dddd")
.peek(s -> seen.incrementAndGet())
.filter(s -> s.length() > 2)
.findFirst(); // 只会 peek 到 "a"、"bb"、"ccc" —— 第三个就匹配了，"dddd" 不会进 peek
System.out.println(seen.get()); // 输出 3，不是 4
这意味着：如果你依赖 peek() 做全局计数，必须确认终端操作是非短路的（如 collect()、forEach()、count()），否则数字永远少于预期。
真实项目里最容易在这里掉坑——日志写了 peek()，结果线上发现计数对不上，最后发现是用了 findAny()。
