peek() 是 java stream 专为调试设计的中间操作，不改变数据流，仅在终端操作触发时对每个元素执行副作用（如日志或断点），适用于快速定位流转逻辑问题，但不可用于生产环境或依赖其执行次数。
Java Stream 的链式调用让代码简洁，但也让调试变得困难——中间结果看不见，出错时难以定位问题。peek() 是 Stream API 中专为调试设计的“观察者”方法，它不改变数据流，只在每个元素经过时执行指定操作，是排查流转逻辑最轻量、最直接的手段。
peek() 的核心用法：插入日志观察流经元素
peek() 接收一个 Consumer，对每个流元素执行副作用操作（如打印），然后原样返回该元素，继续后续处理。它必须出现在中间操作链中，且仅在终端操作触发时才执行。
- 错误写法：单独调用 stream.peek(...) 不会触发任何输出，因为没有终端操作
- 正确写法：必须配合 collect、forEach、count 等终端操作，例如：stream.peek(System.out::println).filter(...).map(...).collect(...)
- 建议在关键节点插入 peek，比如 filter 前后、map 输入/输出处，便于对比变换效果
避免常见陷阱：副作用与执行时机
peek() 的行为高度依赖 Stream 的惰性求值机制。并行流中，元素处理顺序不确定，peek 输出可能乱序；短路操作（如 findFirst）可能导致部分元素 never 被 peek 到。
- 不要在 peek 中修改元素状态（如 setXXX），这违反函数式原则，且可能引发并发问题
- 不要依赖 peek 的执行次数做逻辑判断——Stream 可能被优化跳过某些元素
- 调试并行流时，可在 peek 中打印线程名：peek(x -> System.out.println(Thread.currentThread().getName() + ": " + x))
结合 IDE 调试：在 peek 内部设断点更精准
比起单纯打印，直接在 peek 的 lambda 里加断点，能查看当前元素的完整对象状态、调用栈和变量上下文，尤其适合复杂对象或条件分支场景。
- 在 IDEA 中，在 peek 的大括号内任意一行点击左侧边栏设断点，运行 debug 模式即可停住
- 可配合“Evaluate Expression”实时检查 stream 状态，比如输入 x.toString() 或 x.getRelatedList().size()
- 注意：断点只在实际被处理的元素上触发，未被消费的元素不会停住
替代方案对比：何时用 peek，何时换工具
peek 适合快速验证单次流转逻辑，但不适合长期监控或生产环境。复杂场景建议组合使用：
- 需要结构化日志？用 peek(x -> log.debug("Processing: {}", x)) 配合日志框架
- 想可视化整个流过程？考虑自定义 Collector 或用第三方库如 stream-debugger
- 排查性能瓶颈？优先用 JMH 基准测试 + VisualVM 观察 GC 和 CPU，而非大量 peek 打印
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
