Stream.peek()是无副作用中间操作，仅在终端操作触发时对流经该节点的元素执行动作；需合理定位、避免阻塞/异常、结合结构化日志与采样策略实现可观测性。
Stream.peek() 是一个无副作用的中间操作，它允许你在不改变流元素本身的前提下对每个元素执行一些动作（比如打印日志）。但要注意：它只有在流实际被消费时才会触发，且仅对经过该节点的元素生效。因此，合理放置 peek() 的位置、避免副作用干扰、配合合适的日志结构，是实现“不影响主业务流”的监控日志的关键。
明确 peek() 的触发时机和适用边界
peek() 不是终端操作，它不会启动流的执行；只有调用 collect()/forEach()/count() 等终端操作后，前面所有中间操作（包括 peek）才按顺序逐个作用于每个元素。
这意味着：如果你把 peek 放在 filter 后面，它只会记录通过 filter 的元素；放在 map 后面，则记录的是 map 转换后的值——这对定位问题非常有用，但也容易误判原始输入状态。
用结构化日志 + 元信息增强可观测性
不要只写 System.out.println("处理了: " + item)。建议在 peek 中构造轻量级日志对象，包含：
- 当前处理阶段标识（如 "pre-filter", "post-map", "pre-collect"）
- 元素标识（如 id、traceId，若无则用 hashCode 或序列号）
- 时间戳（Instant.now()，非 new Date()）
- 关键字段快照（如 item.getStatus(), item.getAmount()，避免 toString() 泄露敏感或大对象）
- 可选：线程名（Thread.currentThread().getName()），便于排查并行流行为
避免常见陷阱：别让 peek 变成“伪终端”或引发异常
peek() 内部抛出的受检异常无法直接抛出，必须包装为 RuntimeException；更危险的是：如果 peek 里做了阻塞 I/O（如同步写文件、发 HTTP 请求）、加锁、或调用了可能抛出未捕获异常的方法，会导致整个流中断，违背“不影响主业务流”的前提。
✅ 推荐做法：
- 日志统一走异步 Appender（如 Logback 的 AsyncAppender）
- 使用 MDC（Mapped Diagnostic Context）注入 traceId，让 peek 日志自动关联全链路
- 对高吞吐场景，考虑采样（如每 100 条记录 1 条）避免日志爆炸
- 并行流中，peek 执行线程不确定，勿依赖 ThreadLocal 存状态
结合实际流链路做分层监控示例
假设你有一段用户订单处理流：
orders.stream()
.filter(order -> order.isValid()) // ← 过滤前可 peek 原始订单
.peek(order -> log.debug("filtered-in: {}", order.getId())) // 记录进入 filter 的 ID
.filter(order -> order.getAgeDays() monitor.record("dto-built", dto.getUserId()))
.sorted(comparing(OrderDto::getAmount).reversed())
.limit(10)
.collect(toList());
这个例子中，两个 peek 分别监控了过滤入口和转换结果，既不改变数据，又能清晰看到哪些订单进了流程、哪些生成了 DTO，且完全解耦于业务逻辑。
