Go io.TeeReader 记录请求体为什么会拖慢接口：同步写入、失败传播与流式复制边界

接口为了留一份审计副本，把请求体包成 io.TeeReader 之后，上传接口的耗时突然和磁盘写入速度绑在了一起。这个现象并不难理解：TeeReader 不是后台异步复制器，主读取每拿到一段数据，就会同步写给另一个 io.Writer；写入失败也会顺着读取结果直接返回。

你遇到的拖慢问题本质上是同步读写绑定带来的链路阻塞，把本该后置的审计写入放到了接口主流程里，副写入的所有开销都会直接叠加到接口耗时上。

io.TeeReader 到底把数据写到了哪里

io.TeeReader(r, w) 返回一个新的 Reader。调用它的 Read 时，先从 r 读数据，再把本次读到的字节写入 w。文档里的关键点是“写入必须完成后，读取才算完成”，所以它表达的是一条同步数据链。

type auditWriter struct {
    n   int
    err error
}

func (w *auditWriter) Write(p []byte) (int, error) {
    if w.err != nil {
        return 0, w.err
    }
    w.n += len(p)
    return len(p), nil
}

func copyWithAudit(src io.Reader, audit io.Writer) error {
    tee := io.TeeReader(src, audit)
    _, err := io.Copy(io.Discard, tee)
    return err
}

这里没有第二条独立的 goroutine。审计 Writer 慢，io.Copy 就会等；审计 Writer 返回错误，复制也会停下来。把它放在请求主链路里之前，先问一句：审计副本是请求成功的必要条件，还是事后分析材料？

用一个慢 Writer 看清性能边界

不要先凭感觉把问题归到网络。下面的 Writer 每次写入都暂停 20 毫秒，可以直接观察主读取是否跟着变慢。

type slowWriter struct {
    delay time.Duration
    n     int
}

func (w *slowWriter) Write(p []byte) (int, error) {
    time.Sleep(w.delay)
    w.n += len(p)
    return len(p), nil
}

func main() {
    src := strings.NewReader(strings.Repeat("x", 32*1024))
    audit := &slowWriter{delay: 20 * time.Millisecond}
    start := time.Now()

    _, err := io.Copy(io.Discard, io.TeeReader(src, audit))
    fmt.Println("err:", err, "audit bytes:", audit.n, "elapsed:", time.Since(start))
}

如果底层读取分成多次，延迟就会累积到每次写入。真实文件、远端挂载目录或带限速的对象存储会把这个差异放大。TeeReader 本身没有缓冲、批量落盘或失败重试策略；需要这些能力时，应把它们明确放在 Writer 一侧，并单独测量。

写入失败为什么可能在下一次 Read 才暴露

读取接口允许一次返回“读到了一部分数据，同时带有错误”。因此不能只写成“循环直到 err != nil，然后丢掉 n”。对 io.TeeReader 来说，副 Writer 的错误会影响后续读取，但之前已经成功读出的那段数据仍然由 n 表示。

func drain(r io.Reader) error {
    buf := make([]byte, 32*1024)
    for {
        n, err := r.Read(buf)
        if n > 0 {
            // 先处理这 n 个字节，不能因为 err 非空就丢弃。
        }
        if err == io.EOF {
            return nil
        }
        if err != nil {
            return err
        }
    }
}

生产代码还要检查副本是否完整。审计文件写到一半时，不能把临时文件直接改名成最终文件；应先关闭、校验字节数或哈希，再原子改名。失败路径删除临时文件，避免下一次请求误把半成品当成有效记录。

请求体落盘的最小安全写法

如果需求是“读取请求体，同时保存一份副本”，可以把边界写在同一个函数里：大小限制在外层，临时文件负责中间状态，成功后才提交文件名。

func saveBody(body io.Reader, dir string, maxBytes int64) (string, error) {
    f, err := os.CreateTemp(dir, "body-*.part")
    if err != nil {
        return "", err
    }
    tmp := f.Name()
    committed := false
    defer func() {
        _ = f.Close()
        if !committed {
            _ = os.Remove(tmp)
        }
    }()

    limited := io.LimitReader(body, maxBytes+1)
    n, err := io.Copy(f, limited)
    if err != nil {
        return "", err
    }
    if n > maxBytes {
        return "", fmt.Errorf("body too large: %d", n)
    }
    if err := f.Close(); err != nil {
        return "", err
    }
    final := strings.TrimSuffix(tmp, ".part")
    if err := os.Rename(tmp, final); err != nil {
        return "", err
    }
    committed = true
    return final, nil
}

这个函数展示的是“副本落盘”本身，不代表上传接口可以无限接收数据。实际服务还应在路由层配置请求大小、超时和磁盘配额，并记录请求 ID、实际字节数和失败原因，而不是把完整请求体写进普通业务日志。

常见问题：TeeReader 的几个边界

TeeReader 会自动异步写文件吗？

不会。它只是把读取和写入串成一个同步 Reader。想异步处理，要先决定主请求是否等待副本，并为队列满、进程退出和失败重试设计明确行为。

Write 返回短写但没有错误怎么办？

这是 Writer 契约问题。标准库的复制函数会把短写视为 io.ErrShortWrite 等异常路径处理；自定义 Writer 应保证返回的字节数与实际写入一致，不要静默吞掉短写。

只记录哈希还需要保存完整请求体吗？

不一定。若审计只需要证明内容未被替换，边读边更新 sha256.Hash 的成本通常比落盘低；若还要支持人工复核或失败续传，才需要保存副本，并加上权限、保留期和脱敏规则。

把复制链路收回到可验证的边界

io.TeeReader 的价值在于把一次读取同时送到另一个 Writer，适合哈希、计数和小范围审计。它解决不了慢存储、异步可靠投递或半成品管理。上线前至少做三次核对：慢 Writer 是否会拉长请求耗时，副 Writer 出错时接口是否按预期失败，临时文件是否在所有失败路径被清理。