peek() 是专为调试设计的副作用中间操作，仅用于观察流中元素而不改变数据，必须置于终端操作前且不可替代 map() 或 filter() 等转换操作。
Java Stream API 的 peek() 方法不是用来改变数据的，而是专为“观察”流中元素而设计的调试工具。它在不干扰流执行逻辑的前提下，让你看到每个中间步骤的值，特别适合排查过滤、映射或排序后结果异常的问题。
peek 的本质：副作用操作，不影响流本身
peek() 是一个中间操作，返回的是原流（不是新流），它只对流中每个元素执行你传入的 Consumer 动作，但不会修改元素本身。这意味着：
- 它不能替代
map()或filter()做实际转换或筛选 - 如果流是短路操作（如
findFirst()），peek()只会作用于实际被处理的元素，而非全部 - 必须出现在终端操作（如
collect()、forEach()）之前才生效
典型调试场景：快速定位数据变换断点
比如你发现最终结果为空，但不确定是 filter() 过严，还是 map() 出错：
List<String> result = list.stream()
.filter(s -> s.length() > 3)
.peek(s -> System.out.println("after filter: " + s)) // 查看保留了哪些字符串
.map(String::toUpperCase)
.peek(s -> System.out.println("after map: " + s)) // 确认大小写是否正确转换
.collect(Collectors.toList());输出会逐行显示每一步经过的元素，帮你确认逻辑断点在哪一环失效。
立即学习“Java免费学习笔记（深入）”；
注意事项：避免在生产环境滥用 peek
peek() 中的代码属于副作用（side-effect），违背了函数式编程的纯度原则。因此：
- 不要在
peek()里修改外部变量、写文件或发网络请求——这会让流行为不可预测 - IDE 或某些 JVM 优化可能在特定条件下跳过无用的
peek()（尤其未启用调试模式时） - 更可靠的生产级日志方案是用专门的日志框架（如 SLF4J）配合条件输出，而不是依赖
peek()
替代思路：用自定义工具方法增强可读性
为避免重复写 peek(System.out::println)，可以封装一个辅助方法：
public static <T> Stream<T> trace(Stream<T> stream, String label) {
return stream.peek(t -> System.out.printf("[%s] %s%n", label, t));
}调用时更清晰：
List<Integer> nums = Arrays.asList(1, 2, 3, 4, 5);
trace(trace(list.stream(), "origin")
.filter(x -> x % 2 == 0), "after filter")
.map(x -> x * 2)
.peek(x -> System.out.println("final: " + x))
.collect(Collectors.toList());不复杂但容易忽略：peek 不是银弹，它是调试时的探针，不是流程控制的一部分。用好它，关键在时机和克制。
