如何应用Stream.peek在不改变流变量状态的前提下实现审计日志记录

Stream.peek()适合插入审计日志，需准确定位位置（filter前/后、map后）、记录轻量可追溯信息（阶段标识、追踪ID、关键字段、时间戳）、确保异步非阻塞、异常兜底，并通过MDC实现链路级审计。

搞Ja va流式处理的朋友都知道，peek()本身并不会改变流中元素的值或顺序，天然就是个干审计的料。关键不是“能不能用”，而是“在哪用、怎么写、怎么防崩”。

准确定位 peek 的插入位置

审计日志的价值取决于它反映的是哪一阶段的状态。毕竟peek只对流经它的元素生效，所以位置选不对，日志就白记。那么，到底该把peek塞在哪个位置？

• 放在 filter 前：记录原始输入，适合做全量入参审计
• 放在 filter 后、map 前：记录通过校验的有效数据，适合业务准入审计
• 放在 map 或 flatMap 后：记录转换后的结果快照，适合输出一致性审计
• 多个 peek 可叠加使用，比如同时记录“入参→过滤后→转换后”三段状态

这几种位置各有用途。举个例子，如果业务上需要追溯“哪些原始请求被过滤掉了”，那就在filter前加一个peek；如果更关心“转换后的结果到底长什么样”，那就在map后面加一个。灵活组合，但别贪多——peek多了，代码阅读成本也上去了。

日志内容要轻量且可追溯

想想看，如果在peek里直接打印整个对象的toString()，既占空间又可能泄密，图啥呢？结构化记录才是正解，而且只记最小必要信息就够了：

• 阶段标识：如 "audit:pre-filter"、"audit:post-dto"
• 唯一追踪 ID：优先取业务字段（如 orderId、traceId），没有则用 item.hashCode() 或序列号
• 关键字段快照：只取审计强相关字段，例如 status、amount、channel，不取整个对象
• 时间戳与线程名：Instant.now() + Thread.currentThread().getName()，便于排查时序与并发问题

这里有个小技巧：追踪ID尽量用业务字段，而不是系统生成的hashCode——生产环境里定位问题时，业务字段可比哈希值好用多了。

确保不影响主流程稳定运行

审计日志是旁路行为，不能成为流执行的瓶颈或失败点。说白了，就是不能因为记日志把业务给拖垮了。行业共识是：

• 禁止同步阻塞操作：不直接写文件、不发 HTTP 请求、不调用慢 SQL
• 日志必须走异步 Appender：如 Logback 的 AsyncAppender，避免 I/O 拖慢流处理
• 异常必须吞掉或包装为 RuntimeException：peek 内部抛出未捕获异常会中断整个流
• 高吞吐场景启用采样：例如用 AtomicInteger % 100 == 0 控制每百条记 1 条，防日志刷屏

值得注意的是，异常处理这块特别容易踩坑。peek里如果抛出checked exception，编译器可能不会直接报错，但运行时一旦异常没被捕获，整个流就断了。所以一定要在内层把异常兜住。

配合 MDC 实现链路级审计对齐

如果流处理是嵌套在Web请求或消息消费里的，那就需要让日志带上上下文。怎么搞呢？用MDC呗。

• 在 Controller 或 Listener 入口处：MDC.put("traceId", UUID.randomUUID().toString())
• 在 peek 中直接使用日志框架的占位符：log.info("audit: {} | id={} | status={}", stage, item.getId(), item.getStatus())
• 这样所有审计日志与业务日志共享同一 traceId，可在 ELK 或 Grafana 中一键关联分析

这种做法的好处是，你不需要在每个peek里手动传递traceId。只要入口处设置好MDC，后面的日志框架会自动把上下文带进去，既干净又可靠。从数据来看，配合ELK这类工具，一条链路从请求进来、经过过滤、转换、到最后输出，哪个环节出了问题，一看日志就全清楚了。