Stream.peek()适合插入审计日志，需准确定位位置（filter前/后、map后）、记录轻量可追溯信息（阶段标识、追踪ID、关键字段、时间戳）、确保异步非阻塞、异常兜底，并通过MDC实现链路级审计。
Stream.peek() 本身不改变流中元素的值或顺序，天然适合在不干扰主业务逻辑的前提下插入审计日志。关键不是“能不能用”，而是“在哪用、怎么写、怎么防崩”。
准确定位 peek 的插入位置
审计日志的价值取决于它反映的是哪一阶段的状态。peek 只对流经它的元素生效，因此：
- 放在 filter 前：记录原始输入，适合做全量入参审计
- 放在 filter 后、map 前：记录通过校验的有效数据，适合业务准入审计
- 放在 map 或 flatMap 后：记录转换后的结果快照，适合输出一致性审计
- 多个 peek 可叠加使用，比如同时记录“入参→过滤后→转换后”三段状态
日志内容要轻量且可追溯
避免在 peek 中拼接大对象 toString() 或打印敏感字段。推荐结构化记录以下最小必要信息：
- 阶段标识：如 "audit:pre-filter"、"audit:post-dto"
- 唯一追踪 ID：优先取业务字段（如 orderId、traceId），没有则用 item.hashCode() 或序列号
- 关键字段快照：只取审计强相关字段，例如 status、amount、channel，不取整个对象
- 时间戳与线程名：Instant.now() + Thread.currentThread().getName()，便于排查时序与并发问题
确保不影响主流程稳定运行
审计日志是旁路行为，不能成为流执行的瓶颈或失败点：
- 禁止同步阻塞操作：不直接写文件、不发 HTTP 请求、不调用慢 SQL
- 日志必须走异步 Appender：如 Logback 的 AsyncAppender，避免 I/O 拖慢流处理
- 异常必须吞掉或包装为 RuntimeException：peek 内部抛出未捕获异常会中断整个流
- 高吞吐场景启用采样：例如用 AtomicInteger % 100 == 0 控制每百条记 1 条，防日志刷屏
配合 MDC 实现链路级审计对齐
如果流处理嵌套在 Web 请求或消息消费中，提前将 traceId 注入 MDC，peek 日志就能自动带上上下文：
- 在 Controller 或 Listener 入口处：MDC.put("traceId", UUID.randomUUID().toString())
- 在 peek 中直接使用日志框架的占位符：log.info("audit: {} | id={} | status={}", stage, item.getId(), item.getStatus())
- 这样所有审计日志与业务日志共享同一 traceId，可在 ELK 或 Grafana 中一键关联分析
