peek是Java Stream中用于调试的中间操作，接收Consumer对每个元素执行消费动作（如打印），但需终端操作触发才能执行，不改变元素且不影响流结构。
peek 是 Java Stream 中一个不改变元素本身、仅用于“窥探”中间过程的中间操作，常用于调试时打印流中每个元素的状态，而不会干扰后续处理逻辑。
peek 的核心特性与使用前提
peek 接收一个 Consumer<T>，对流中每个元素执行消费动作（如打印），但必须有终端操作触发，否则 peek 不会执行——因为 Stream 是惰性求值的。
- peek 属于中间操作，返回新流，可链式调用
- 它不修改元素，也不影响流的结构或顺序
- 若流未被终端操作（如
collect()、forEach()、count()）触发，peek 内的代码根本不会运行
典型调试场景：查看过滤/映射前后的元素
比如想确认 filter 是否按预期剔除了数据，或 map 是否正确转换了字段：
List<String> result = Arrays.asList("apple", "banana", "cherry", "date")
.stream()
.peek(s -> System.out.println("原始: " + s))
.filter(s -> s.length() > 5)
.peek(s -> System.out.println("通过 filter: " + s))
.map(String::toUpperCase)
.peek(s -> System.out.println("转大写后: " + s))
.collect(Collectors.toList());
输出会清晰展示每一步流中实际存活的元素，帮你快速定位逻辑断点。
立即学习“Java免费学习笔记（深入）”；
注意事项与常见误区
peek 不适合做有副作用的业务逻辑（如修改对象状态、写文件、发请求），因为：
- 并行流中执行顺序不确定，可能导致日志乱序或重复执行
- 短路操作（如
findFirst()）可能只处理部分元素，peek 也不会全量触发 - 若流被多次复用（错误地重复调用 collect），peek 可能执行多次——Stream 不能重用，每次都要重建
替代方案建议：何时不用 peek
如果需要更可控的日志行为，或需在终端阶段统一汇总，可考虑：
- 在终端操作中手动遍历（如用
forEach打印再收集） - 用
map包装元素为带上下文的对象，再处理 - 结合 IDE 调试器设置断点，比日志更直观
peek 是轻量级调试利器，用对了省时省力，用错了反而增加困惑。
