Java 9 及以上 Stream.count 返回数量，但 peek 没有执行

一条流先 map() 转换元素，再用 peek() 打印，最后调用 count()。计数返回正常，控制台却没有逐项输出。这在 Java 9 及以上可能是允许的优化：源已经知道元素数量，而中间操作不改变数量，count() 可以直接得到答案，不必遍历元素。

例如下面的代码中，列表有三个元素，乘法和打印都不会改变元素个数：

List<Integer> values = Arrays.asList(2, 4, 6);
long count = values.stream()
    .map(n -> n * 3)
    .peek(System.out::println)
    .count();

count 应为 3，但不能据此认定乘法和打印已逐项执行。这里针对标准 java.util.stream 的计数优化，尤其是集合等已知大小的数据源；并不是说所有流的 peek() 都不会运行。

终止操作存在，也不保证每个中间动作执行

没有终止操作时，惰性流通常还没开始遍历；本例已经有 count()，因此仅补一个终止操作不能解释或修复这个现象。

计数只需要数量。若实现能在不影响最终结果的前提下省略某个阶段，就允许跳过它的回调。Java 9 的 count() 文档已明确这一点，当前 API 也保留了相同约定。不要依赖旧运行环境中的一次打印结果来保证升级后的行为。

排查时确认 IDE、测试和实际进程使用的 JDK，再看整条处理链：源是否已知大小，后面是否只有不改变数量的操作，以及调用方真正需要的是计数还是逐项动作。把 peek() 改成带副作用的 map()，再接 count()，并没有改变这个依赖问题。

需要逐项输出，就把输出作为终止操作

下面是完整的纯演示程序，使用 forEachOrdered() 明确要求按有序流的遇见顺序执行打印：

import java.util.Arrays;
import java.util.List;

public class PrintValues {
    public static void main(String[] args) {
        List<Integer> values = Arrays.asList(2, 4, 6);
        values.stream()
            .map(n -> n * 3)
            .forEachOrdered(System.out::println);
    }
}

按这里的输入，应依次打印 6、12、18。如果动作顺序无关，也可以按需求使用 forEach()；并行流的 forEach() 不保证遇见顺序。不要为修复漏执行顺手改成并行流，尤其是动作会访问共享状态或外部服务时。

peek() 可以用于观察经过某个阶段的元素，但调试输出可能被短路或优化省略。因此它不适合承担必须完成的保存、校验、通知等业务动作。

同时需要动作和数量，可以用明确的循环

如果真实目标是“处理每条记录，并统计已完成多少条”，普通循环更容易交代完成条件：

import java.util.Arrays;
import java.util.List;

public class PrintAndCount {
    public static void main(String[] args) {
        List<Integer> values = Arrays.asList(2, 4, 6);
        long processed = 0;
        for (int value : values) {
            int converted = value * 3;
            System.out.println(converted);
            processed++;
        }
        System.out.println("processed=" + processed);
    }
}

该例只打印演示数值。换成业务操作时，计数应放在你定义的成功边界之后；一次方法正常返回不一定代表异步任务已完成。操作抛出异常后，先前已产生的外部副作用也不会自动撤销，重试仍需要业务层的幂等或恢复规则。

如果既要转换结果集合又要动作，可以先完成结果收集，再对结果执行明确的动作；是否值得保留整个集合要结合数据量判断。不要为了计数再次消费已经用过的同一个 Stream。

不用恒真 filter 维持副作用

加入 filter(x -> true) 可能让某个实现需要重新遍历，从而暂时看见打印。但这把业务正确性绑在优化细节上，也让没有筛选含义的条件留在处理链中。应改成明确要求动作的终止操作或循环。

验证修复时，在无外部副作用的小样例上分别核对空输入、单个元素、多个元素的动作次数和顺序。需要计数时同时核对数量，而不是只看最终 count() 的返回值。保留原实现便于回退代码；如果旧逻辑漏掉了真实业务动作，应依据业务记录补偿，不能直接重跑生产数据来“看看是否执行”。