Go io.Copy 如何避免无界读取：ReaderFrom、LimitReader 与吞吐基线

上传接口或内部代理收到一个没有可靠长度标记的请求体时，直接调用 io.Copy 很容易把“读到 EOF”误当成“输入一定合理”。更稳的做法是先用 io.LimitReader 给输入加上业务上限，再让 io.Copy 按 WriterTo 或 ReaderFrom 选择快路径，最后用同一组数据做基准对照。

io.Copy 负责搬运，不负责替你限制输入。把边界放在源端，用 LimitReader 控制最多读取的字节数；目标端若实现 ReaderFrom，复制过程会优先走目标端的读取路径。

先看清 io.Copy 的结束条件

io.Copy(dst, src) 的语义很窄：从 src 复制到 dst，直到源端返回 EOF 或某个错误。它不会猜测上传大小，也不会因为目标是文件就自动拒绝超大输入。官方实现会先尝试源端的 WriterTo，源端没有时再尝试目标端的 ReaderFrom，最后才回到内部缓冲区循环。

n, err := io.Copy(dst, io.LimitReader(src, maxBytes))
if err != nil {
    return fmt.Errorf("copy request body: %w", err)
}
if n == maxBytes {
    return errors.New("input reached the configured limit")
}

这里的 n == maxBytes 只能说明已经写了上限这么多字节，不能单独证明源端还有剩余内容。若业务必须区分“刚好等于上限”和“超过上限”，可以再读取一个字节做超限探测；不要把 io.Copy 的成功当成大小校验结果。

把 LimitReader 放在输入边界

io.LimitReader(src, maxBytes) 返回一个最多读取 maxBytes 字节的 Reader。它包装的是输入，不改变目标端的写入逻辑，所以文件保存、哈希计算或响应转发都可以沿用同一套边界。

func saveBody(dst io.Writer, src io.Reader, maxBytes int64) (int64, error) {
    limited := io.LimitReader(src, maxBytes+1)
    n, err := io.Copy(dst, limited)
    if err != nil {
        return n, err
    }
    if n > maxBytes {
        return n, fmt.Errorf("body exceeds %d bytes", maxBytes)
    }
    return n, nil
}

示例故意把读取预算设成 maxBytes+1。这样可以把“恰好达到上限”和“确实多出至少一个字节”区分开来。超过上限时，调用方还应决定是否删除已经写入的临时文件，或者把目标换成可回滚的缓冲区；LimitReader 本身不会撤销已发生的写入。

ReaderFrom 快路径为什么值得测

如果目标实现了 io.ReaderFrom，io.Copy 会调用目标的 ReadFrom；如果源实现了 io.WriterTo，则会优先调用源的 WriteTo。例如文件目标、网络连接或自定义缓冲器可能拥有不同的实现，包装一层 Reader 也可能让原先可识别的接口不再直接暴露。

性能结论要建立在实测上。基准至少应比较普通源、带 LimitReader 的源和不同目标类型；输入内容、大小、是否预分配以及 Go 版本都要固定。没有这些条件，“ReaderFrom 更快”只能算推测。

用固定基准观察吞吐与分配

下面的基准不写死某台机器的数字，而是把关键变量固定下来，让每次运行都能得到自己的基线。b.SetBytes 让测试输出吞吐口径，io.Discard 避免磁盘或网络成为主要变量。

func BenchmarkCopyLimit(b *testing.B) {
    payload := bytes.Repeat([]byte("g"), 1

执行 go test -bench BenchmarkCopyLimit -benchmem -count=5 后，先记录每轮的 ns/op、MB/s 和 B/op，再改变一个变量重跑。若把 LimitReader 去掉，比较的是边界包装的成本；若替换目标类型，比较的是目标接口路径。不要把不同输入长度的结果放在同一张表里直接下结论。

错误、超限和回滚要分开处理

复制返回 err == nil 只代表源端正常结束或限制 Reader 正常返回 EOF。它不代表目标文件已经符合业务要求，也不代表请求体没有超过协议上限。对上传类场景，我更建议把复制、超限判断和临时文件提交拆成三个阶段：复制到临时目标，确认 n ，再原子改名。

n, err := saveBody(tmp, req.Body, 8 8

如果目标不是可删除的临时文件，而是已经发出的网络响应，就不能事后回滚远端副作用。这时应在写入前限制输入，必要时配合请求头、超时和上游协议校验。

相关问题

io.Copy 会自动限制读取大小吗？

不会。它默认持续读取到源端 EOF；需要大小上限时，应显式包装 io.LimitReader 或在协议层使用对应的请求限制机制。

为什么用了 LimitReader 还要关注 n？

因为达到限制后可能正常返回 EOF。通过读取 maxBytes+1 并检查 n，才能区分恰好达到上限和确实超限。

ReaderFrom 一定比内部缓冲循环快吗？

不一定。它改变了调用路径，但实际收益取决于源、目标、系统调用和数据大小；应在固定环境下用 go test -bench 实测。

把复制链路留在可验证边界内

最终检查可以压缩成四项：输入是否有明确上限，超限是否能被识别，目标端的提交是否可回滚，以及基准是否固定了比较条件。满足这四项后，io.Copy 才既是搬运工具，也是可审计的数据路径。