Stream.peek()是Java 8中用于调试的中间操作，可在不终止流、不改变元素的前提下对每个消费元素执行副作用操作（如打印日志），适用于链式处理中定位filter、map等操作前后的状态。
Stream.peek() 是 Java 8 Stream API 中一个常被低估的调试工具：它允许你在不干扰流元素本身、不改变流结构、不终止流的前提下，对每个经过的元素执行任意操作（比如打印日志）。它本质是“旁路观察”，非常适合在链式处理中插入临时诊断信息。
理解 peek() 的核心行为
peek() 是一个中间操作，返回一个新的流，其元素与原流完全一致。它只在元素被消费时（即下游操作实际拉取元素时）才触发传入的 Consumer。这意味着：
- 如果流没有被终端操作（如 collect、forEach、count）触发，peek 中的代码根本不会执行；
- 它不会过滤、映射或重组数据，只是“路过时看一眼”；
- 适用于调试 filter、map、sorted 等中间操作前后的状态变化。
典型调试场景与写法
假设你有一段处理用户订单的流：
List<Order> result = orders.stream()
.filter(o -> o.getAmount() > 100)
.peek(o -> System.out.println("✅ 过滤后保留: " + o.getId())) // 查看哪些通过了 filter
.map(Order::toDto)
.peek(dto -> System.out.println("? 映射为 DTO: " + dto.getOrderId())) // 检查 map 输出
.sorted(Comparator.comparing(OrderDto::getAmount))
.peek(dto -> System.out.println("? 排序后首项: " + dto.getOrderId())) // 注意：peek 在每轮迭代都执行，这里会打多次，慎用
.limit(5)
.collect(Collectors.toList());
关键点：
- 每个 peek() 紧跟在对应中间操作之后，能精准定位该步输出；
- 避免在 peek 中做耗时或有副作用的操作（如写文件、发 HTTP 请求），它不是设计用于业务逻辑；
- 若只想看头几个元素，可配合 limit 使用，减少日志量。
替代方案对比：为什么不用 forEach？
forEach 是终端操作，一旦调用就会消费整个流，后续无法继续链式处理。例如：
orders.stream()
.filter(...).forEach(System.out::println) // ❌ 流已结束，后面不能再 map 或 sorted
.map(...); // 编译错误！
而 peek 不会终止流，完美适配“边走边看”的调试需求。
进阶技巧：封装可复用的调试 peek
为避免重复写 System.out.println，可以封装一个工具方法：
public static <T> Consumer<T> log(String prefix) {
return t -> System.out.printf("[DEBUG %s] %s%n", prefix, t);
}
// 使用：
orders.stream()
.peek(log("原始输入"))
.filter(...)
.peek(log("过滤后"))
.map(...)
.peek(log("最终DTO"));
这样日志带上下文标签，更易追踪各环节。
不复杂但容易忽略：peek 不是银弹，它依赖流的实际执行时机，且过度使用会影响可读性。建议仅在开发/测试阶段启用，上线前移除或通过日志级别控制。
