Stream.peek()是Java 8中用于调试流的中间操作，可在不中断流程下对每个元素执行副作用（如日志），但仅在终端操作触发时惰性执行，且不可替代forEach()、避免修改状态、并行流中顺序不保证。
Stream.peek() 是 Java 8 Stream API 中一个常被低估的调试工具，它允许你在不中断流处理流程的前提下，对每个元素执行副作用操作（比如打印、记录日志），非常适合观察中间状态。
peek() 的核心作用和限制
peek() 是一个中间操作，返回一个新的流，其行为是在每次元素被消费前，先执行你传入的 Consumer。它不会改变流中元素本身，也不影响后续操作逻辑，但仅在流实际执行终端操作时才会触发（即惰性求值）。如果流没有被消费（比如漏掉了 collect()、forEach() 等终端操作），peek() 里的代码根本不会运行。
正确使用 peek() 调试的典型场景
以下写法能清晰看到每一步处理前的数据状态：
- 过滤前查看原始数据：
stream.peek(System.out::println).filter(x -> x > 10) - 映射前观察输入值：
stream.filter(...).peek(x -> System.out.println("Before map: " + x)).map(String::valueOf) - 分组或归约前检查中间结果：
stream.peek(x -> log.debug("Processing: {}", x)).collect(Collectors.groupingBy(...))
容易踩的坑与注意事项
peek() 不是万能调试器，需注意几点：
- 不要用 peek() 替代 forEach() 做最终输出——它只适用于“顺路看一眼”，终端操作才是负责真正消费的环节
- 避免在 peek() 中修改元素状态（如改变对象字段），这会破坏不可变性原则，且可能引发并发问题
- 并行流中 peek() 的执行顺序不保证，日志可能乱序；如需严格顺序，改用 forEachOrdered() 或临时转为串行流
- 生产环境慎用含 System.out.println 的 peek()，建议配合 SLF4J 等日志框架，并控制日志级别（如 debug）
替代方案：更安全的调试方式
若 peek() 不够用，可考虑：
- 把流链拆成多个变量，每步单独 collect 并打印，适合复杂逻辑分段验证
- 封装调试辅助方法，例如
static <T> Stream<T> debug(Stream<T> s, String label) { return s.peek(x -> log.debug("{}: {}", label, x)); } - 使用 IDE 的 Stream Debugger（IntelliJ 支持可视化断点调试流），无需改代码
