Go io.TeeReader 如何记录请求体又不改写读取链：调试与流式处理边界

接口解析失败时，先把请求体留一份现场通常很有用，但直接 io.ReadAll(req.Body) 又会让后面的 JSON 解码器读到空内容。io.TeeReader 的解决方式很窄也很实用：每次下游读取原始流时，同步把同一批字节写入另一个 io.Writer，读取链本身继续向前走。

io.TeeReader 不是可回放缓存，也没有内部缓冲；它只复制“已经被读取”的字节，而且目标写入完成前不会让本次 Read 返回。

io.TeeReader 解决的是读取链旁路记录

假设一个 HTTP handler 需要把请求体交给 json.Decoder，同时保留一份小型调试样本。最小连接关系是 req.Body → io.TeeReader → json.Decoder，旁路写入 bytes.Buffer。这里的“旁路”不是复制一个新的可读流，而是把同一次读取产生的字节再写一份。

最小示例：解析成功后再查看缓冲区

下面的代码刻意让解码器成为唯一读取者。io.TeeReader 只在 decoder.Decode 触发底层 Read 时写入 bytes.Buffer：

type CreateRequest struct {
    Name string `json:"name"`
}

var audit bytes.Buffer
tee := io.TeeReader(req.Body, &audit)
decoder := json.NewDecoder(tee)

var input CreateRequest
if err := decoder.Decode(&input); err != nil {
    // audit.Bytes() 只包含已经被读取的字节
    return err
}
log.Printf("name=%q body_bytes=%d", input.Name, audit.Len())

如果请求体中有多个 JSON 值，第一次 Decode 只会读取到它需要的范围，缓冲区也只代表这次读取实际经过的字节。要记录整个流，必须继续读取到 EOF；但这样会改变处理时机和内存成本，不能把“旁路记录”误解成“自动读完”。

无缓冲与写入错误决定了它的边界

这条规则来自 Go 官方 io 文档：写入必须完成，读取才会完成；写入端的错误不会被静默吞掉。因此把慢速网络写入器直接放在这里，会把它加入请求的关键路径。

把请求体放进日志前先设大小和敏感字段边界

调试接口可以使用 io.LimitReader 限制旁路副本大小，再交给 io.TeeReader。但限制器只限制写入的副本，不会自动限制原始请求体的解析范围；请求大小仍应由 HTTP 层或业务校验单独控制。

const maxAuditBytes = 8 

如果 JSON 里含有 password、access_token 或身份证号，限制长度仍不等于脱敏。更稳妥的做法是记录请求 ID、解析结果中的非敏感字段和长度，把原文留在受控的故障取证流程里。

常见问题

io.TeeReader 会让请求体可以读两遍吗？

不会。它只是把已经读出的字节写给 Writer；第二个读取者若要重放，需要使用已经保存且受控的副本。

为什么缓冲区比请求体短？

因为缓冲区只收到下游实际读取的字节。解析器提前结束、读取失败或只调用了一次 Read，都可能留下未经过旁路的尾部。

Writer 很慢会发生什么？

Read 会等待写入完成，所以慢 Writer 会增加调用链延迟。不要把远程日志接口直接作为同步 Writer。

出错时只检查 Decode 返回值够吗？

不够。旁路 Writer 的错误可能已经通过包装后的读取链返回；应结合错误上下文判断是原始 Reader 还是记录目标失败。

把 io.TeeReader 放在读取链最靠近数据入口的位置，就能在不改写下游解析器的前提下得到有限现场。它适合短期调试和受控审计，不适合代替请求体缓存、消息重放或脱敏系统。