Go 怎样边读取边复制输入流

在 Go 里，如果一份输入只能顺序读取，但你又想把读到的内容同时保存、计算摘要或写入备份文件，可以把原始 io.Reader 包在 io.TeeReader 外面。它会把每次读取到的字节同步写入另一个 io.Writer，读取方仍然只需要面对一个 Reader。

用 io.TeeReader 的关键是把它放在真正的消费方前面：消费方读多少，就复制多少；复制目标写失败，这次读取也会失败。它没有内部缓冲，也不会在后台启动一个复制协程。

这次只讨论标准库 io.TeeReader 的同步复制和错误传播，不把它当成异步分发器或可回放缓存。

io.TeeReader 解决的不是双重读取

输入流通常只能向前消费。若先把整份数据读入内存，再交给业务逻辑和备份逻辑，代码会多出一份完整缓存；若让两个消费者分别读取同一个 Reader，后一个消费者拿不到前一个已经消费的字节。

io.TeeReader 的做法是包装原始 Reader。业务代码读取包装后的 Reader 时，TeeReader 先从原始 Reader 取得一段字节，再把这一段写给目标 Writer，最后把读取结果交给业务代码。因此它复制的是“已经被消费的字节”，不是提前把整个输入流扫描一遍。

先用 bytes.Buffer 看清最小用法

下面的例子把字符串 Reader 包装成 TeeReader，并让 bytes.Buffer 接收复制结果。io.ReadAll 读取 TeeReader 完成后，业务结果和副本内容应当一致。

package main

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

func main() {
	// 原始输入只提供一个顺序读取入口。
	source := strings.NewReader("order=2026-10-17&status=paid")
	var copyBuf bytes.Buffer

	// 每次从 tee 读取时，读到的字节也会同步写入 copyBuf。
	tee := io.TeeReader(source, ©Buf)
	data, err := io.ReadAll(tee)
	if err != nil {
		// 读取错误也可能来自复制目标的 Write 失败。
		panic(err)
	}

	fmt.Printf("业务数据: %s\n", data)
	fmt.Printf("复制数据: %s\n", copyBuf.String())
}

这里没有第二次读取 source。source 的数据只被 TeeReader 消费一次，copyBuf 得到的是这些读取动作产生的副本。若后续代码没有真正读取 tee，复制也不会发生。

把 TeeReader 接到 io.Copy 前面

需要把输入流写入目标文件，同时保留一份用于摘要、审计或调试时，可以让 io.Copy 消费 TeeReader。下面的副本目标使用哈希 Writer，表示“边传输边计算摘要”的常见组合；哈希本身不保存原文，适合只需要校验值的场景。

package main

import (
	"crypto/sha256"
	"encoding/hex"
	"fmt"
	"io"
	"strings"
)

func main() {
	// 输入可以替换为文件、HTTP 响应体或请求体。
	source := strings.NewReader("stream payload")
	hasher := sha256.New()
	tee := io.TeeReader(source, hasher)

	// Copy 消费 tee 时，读出的每个分块都会先写入 hasher。
	count, err := io.Copy(io.Discard, tee)
	if err != nil {
		// 这里统一处理源 Reader 和副本 Writer 的错误。
		panic(err)
	}

	digest := hex.EncodeToString(hasher.Sum(nil))
	fmt.Printf("读取字节数: %d\n摘要: %s\n", count, digest)
}

把 io.Discard 换成文件或网络目标即可形成“主输出 + 同步副本”的组合。要注意，io.Copy 读到哪里，TeeReader 就复制到哪里；复制并不会脱离主消费进度单独继续。

Writer 出错时，Read 也会失败

io.TeeReader 没有内部缓冲，目标 Writer 的写入必须完成后，当前 Read 才能返回。若 Writer 返回错误，这个错误会作为读取错误交给调用方。因此不能只检查“原始输入有没有读错”，还要检查消费 TeeReader 的函数返回值。

可以用一个会失败的 Writer 观察这个边界：

package main

import (
	"errors"
	"fmt"
	"io"
	"strings"
)

type failWriter struct{}

func (failWriter) Write(p []byte) (int, error) {
	// 模拟备份盘、网络目标或限额写入失败。
	return 0, errors.New("copy target is unavailable")
}

func main() {
	tee := io.TeeReader(strings.NewReader("payload"), failWriter{})
	_, err := io.ReadAll(tee)
	if err != nil {
		// ReadAll 报出的错误可能来自 failWriter，而非源 Reader。
		fmt.Println("读取链路失败:", err)
		return
	}
	fmt.Println("读取完成")
}

生产代码中不要为了让主流程继续而无条件忽略这个错误。若复制目标只是可选观测，应该在架构上明确降级策略；若副本承担审计、校验或持久化职责，则应把这个错误当成主流程失败的一部分。

只复制实际消费到的部分

TeeReader 的副本边界由读取方决定。读取方只取前几百字节，副本就只有前几百字节；读取方提前返回或发生错误，后面的输入也不会自动出现在 Writer 中。这一点适合截取调试前缀，但不适合把它误认为完整备份。

package main

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

func main() {
	var copied bytes.Buffer
	tee := io.TeeReader(strings.NewReader("abcdef"), &copied)

	// LimitReader 只消费前三个字节，TeeReader 也只会复制这三个字节。
	part, err := io.ReadAll(io.LimitReader(tee, 3))
	if err != nil {
		panic(err)
	}

	fmt.Printf("业务读取=%q，副本=%q\n", part, copied.String())
}

如果目标是完整留存，应确保主消费方读到 EOF，并根据业务需要处理关闭、落盘和错误；如果目标只是摘要或采样，则可以主动限制读取范围。

它和其他复制方式有什么区别

简单判断方法是：如果你手里只有一个输入 Reader，想在不改变消费接口的情况下旁路写出一份数据，用 TeeReader；如果你已经在写数据并需要多个输出，再考虑 MultiWriter。

使用前的几个取舍

• 速度由较慢的一侧决定：每次读取都要等待 Writer 完成，慢磁盘、慢网络或复杂编码都会直接拖慢主读取。
• 它不是异步队列：需要解耦延迟时，应显式设计带容量和失败策略的队列，而不是把 TeeReader 当作后台复制器。
• 它不自动回放：副本 Writer 如果是 bytes.Buffer，后续可以读取 Buffer；但 TeeReader 本身不能让原始 Reader 倒退。
• 错误必须向上处理：读取函数返回的错误可能来自源 Reader，也可能来自 Writer，日志中最好标明当前复制目标。

常见问题

TeeReader 会不会把输入流完整缓存下来？

不会。它没有内部缓冲，按读取方的节奏处理当前数据；需要完整副本时，必须让读取方持续消费到 EOF，并由 Writer 自己保存数据。

Writer 写入失败，原始 Reader 还能继续读吗？

从当前 TeeReader 的调用结果看，这次读取会返回写入错误。是否能从底层 Reader 继续恢复取决于底层 Reader 和业务设计，不能把 TeeReader 当成自动重试器。

只想记录前缀时能用 TeeReader 吗？

可以。把 TeeReader 放在 io.LimitReader 或自定义读取边界前面，并明确副本只代表实际消费到的前缀，不要把它标记成完整原文。