peek是Stream API中无副作用的中间操作，用于调试时查看流元素而不改变流结构；它仅在终端操作执行时触发，适用于日志、断点调试等场景，但不可修改状态、抛异常或用于并行流顺序调试。
peek 是 Stream API 中一个无副作用的中间操作，它允许你在流元素经过时“偷看”一下数据，执行任意逻辑（比如打印、记录、断点调试），但不会改变流本身的内容或结构，也不会终止流的执行——这正是它适合调试的核心原因。
peek 的基本用法和关键限制
peek 接收一个 Consumer<T>，对每个元素执行消费动作，然后原样向下传递该元素。注意：peek 只在流实际执行终端操作（如 collect、forEach、count）时才会触发；如果只有中间操作（比如 map、filter + peek），流不会运行，peek 也不会执行。
- ✅ 正确：`list.stream().peek(System.out::println).map(String::length).collect(Collectors.toList())` → 会打印原始元素
- ❌ 无效：`list.stream().peek(System.out::println).map(String::length)` → 没有终端操作，什么都不会输出
用 peek 做轻量级日志与数据快照
在复杂链式调用中，你可以在任意位置插入 peek 查看中间结果，快速定位过滤或转换是否符合预期：
- 查 filter 是否误删：`stream.peek(x -> System.out.println("before filter: " + x)).filter(...).peek(x -> System.out.println("after filter: " + x))`
- 验 map 转换逻辑：`stream.peek(System.out::println).map(x -> x * 2).peek(System.out::println)`
- 配合 IDE 断点：`stream.peek(x -> { System.out.println(x); /* 在此行打个断点 */ })`，调试时可直接观察变量值
避免常见陷阱
peek 不是万能调试器，用错反而引入问题：
立即学习“Java免费学习笔记（深入）”；
- ⚠️ 不要修改元素状态（尤其对可变对象）：`stream.peek(x -> x.setName("test"))` 属于副作用，破坏了函数式原则，且可能影响后续逻辑
- ⚠️ 不要在 peek 里抛异常：它不会被 try-catch 包裹，会导致整个流中断并抛出 RuntimeException
- ⚠️ 并行流中 peek 执行顺序不确定：`parallelStream().peek(...)` 的打印/断点可能乱序，不适合依赖顺序的调试
- ⚠️ 不替代 proper logging：生产环境应移除或禁用 peek 日志，避免性能损耗和日志污染
比 peek 更稳的替代思路（按需选用）
若 peek 不够用，可考虑这些更可控的方式：
- 临时拆分流：把长链拆成带变量的步骤，每步后加普通日志或断点
- 用自定义工具方法封装：比如 `logAndReturn("tag", obj)` 返回 obj 同时打印，语义更清晰
- 启用 IDE 的 Stream Trace 功能（IntelliJ Ultimate）：可视化整个流的中间状态，无需改代码
- 单元测试分段验证：对每个中间操作单独写测试，比运行时 peek 更可靠
