Go io.TeeReader 如何同时保存读取内容和传给下游

处理上传文件或 HTTP 请求体时，经常会遇到一个看似矛盾的需求：业务代码要继续读取流，调试或审计又想留下原始字节。io.TeeReader 的答案是把“保存”放到读取动作旁边：下游每读一段，TeeReader 就把这一段同步写给另一个 io.Writer。

它不是把一个流变成两个可以各自随便读取的副本，而是返回一个新的 Reader；只有真正从这个 Reader 读过的数据，才会进入 Writer。Writer 写失败时，读取也会失败。

先画清 io.TeeReader 的数据方向

调用 io.TeeReader(r, w) 后得到的仍是一个 io.Reader。后续代码必须读取返回值 tee，而不是再次读取原来的 r。每次读取由 TeeReader 先从 r 拿到字节，再调用 w.Write；因此它适合给已有的解码器、复制函数或上传处理器加一条旁路。

官方语义还有两个容易忽略的词：没有内部缓冲，以及写入必须完成后读取才完成。也就是说，w 如果是慢磁盘、网络 Writer 或会阻塞的自定义 Writer，读取方会承担这段等待。

用 bytes.Buffer 同时保存并交给下游

下面的例子把同一段文本交给下游读取，同时把读过的内容留在内存缓冲中。注释说明了数据方向和错误处理；示例输出是代码语义对应的结果示意。

package main

import (
    "bytes"
    "fmt"
    "io"
    "strings"
)

func main() {
    source := strings.NewReader("order_id=G20260914&amount=39.90")
    var audit bytes.Buffer
    tee := io.TeeReader(source, &audit)

    // 只有消费 tee，audit 才会收到同样的字节；原 source 不要再单独读取。
    downstream, err := io.ReadAll(tee)
    if err != nil {
        // Writer 写失败会从 TeeReader 的 Read 返回，不能只检查下游结果。
        panic(err)
    }
    fmt.Printf("downstream=%s\naudit=%s\nsame=%t\n", downstream, audit.String(), bytes.Equal(downstream, audit.Bytes()))
}

对应的结果是 downstream 与 audit 内容一致，same=true。如果只创建了 tee 却没有继续读取，它不会主动预读，缓冲区自然仍为空。这一点很适合接入已有的 json.Decoder：把 tee 交给解码器，解码器读到多少，旁路就记录多少。

文件、限流与错误要一起处理

请求体可能远大于预期，直接把它 Tee 到 bytes.Buffer 会让内存随输入增长。保存到文件前先用 io.LimitReader 设上限，并把返回的读取字节数与错误交给调用方判断。

auditFile, err := os.CreateTemp("", "go-audit-*.bin")
if err != nil {
    return err
}
defer os.Remove(auditFile.Name()) // 示例结束后清理临时审计文件
defer auditFile.Close()            // 关闭文件，避免句柄泄漏

// 先限制审计副本大小，再让业务读取 tee；超出上限的部分不会被保存。
limited := io.LimitReader(requestBody, 2

这里的上限只约束了交给 TeeReader 的那条流。如果业务还需要完整请求体，就要明确“审计副本最多保存多少”和“业务是否必须完整读取”是两个决策，不能误以为限流只影响旁路。对于不可重复读取的网络流，TeeReader 也不会提供回放能力；需要回放时应使用受控临时文件或分块存储，并记录长度。

把安全边界放在 Writer 一侧

从威胁建模角度看，被保护的资产是请求中的凭证、个人信息和业务载荷，攻击路径通常是“大输入撑爆内存”或“审计副本泄露敏感字段”。TeeReader 本身不识别 JSON、密码或日志级别，它会忠实地写入 Writer，所以脱敏、截断和访问控制必须放在 Writer 或更早的输入层。

最后可以用四项清单复查：是否读取了 TeeReader 返回值；Writer 是否有明确的失败策略；输入是否有限长；保存内容是否经过脱敏。满足这四点时，TeeReader 就是轻量的读取旁路，而不是隐形的第二份无限副本。

常见问题

io.TeeReader 会不会让原 Reader 可以被读取两次？

不会。它只在一次顺序读取中把已读字节写给 Writer；需要重新读取时必须另行缓存或落盘。

Writer 写入失败时应该检查什么？

检查消费 TeeReader 的 ReadAll、io.Copy 或解码流程返回的错误，因为写入错误会被转成读取错误返回。