Go 的 io.Copy 为什么会突然变慢：ReaderFrom、WriterTo 与包装器边界

文件上传接口突然慢了，日志里却看不到明显的网络重试。把排查范围缩到 Go 的 io.Copy 后，常见的误判是“缓冲区太小”。实际上，io.Copy 会优先检查源端的 WriterTo 和目标端的 ReaderFrom；给 Reader 或 Writer 加上一层包装器后，这两个接口可能消失，复制路径也就变了。

io.Copy 的性能问题十有八九不是默认缓冲不够，而是包装层悄悄抹掉了底层自带的零拷贝能力，让原本的高效直连路径退化成了逐块读写的普通循环。

io.Copy 的快路径到底在什么时候生效

标准库的规则很直接：如果 src 实现了 io.WriterTo，调用 src.WriteTo(dst)；否则，如果 dst 实现了 io.ReaderFrom，调用 dst.ReadFrom(src)；两个接口都没有时，才使用内部缓冲区循环读写。

这不是一个可以手动“开启优化”的开关，而是运行时自动做的接口类型断言。对调用方来说，变量声明成 io.Reader 并不等于底层类型的能力被永久抹掉；真正传给 io.Copy 的动态值，才决定这次复制能不能命中快路径。

package main

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

type traceWriter struct {
    io.Writer
    readFromCalls int
}

func (w *traceWriter) ReadFrom(r io.Reader) (int64, error) {
    w.readFromCalls++
    return io.Copy(w.Writer, r)
}

func main() {
    var dst traceWriter
    dst.Writer = new(bytes.Buffer)
    _, _ = io.Copy(&dst, strings.NewReader("hello"))
    fmt.Println("ReaderFrom calls:", dst.readFromCalls)
}

这里的计数器只能说明目标端是否被选中。换成 strings.Reader 这类带有 WriteTo 能力的源对象后，源端优先级更高，traceWriter.ReadFrom 可能不会被调用。诊断时要同时观察两端，别把“没有进 ReaderFrom”误判成“没有快路径”。

为什么加一层包装器后复制速度会掉下来

项目里经常会在复制前加统计、限速、哈希或日志包装器。包装器如果只声明 Read，就不再向外暴露底层的 WriterTo；目标端也可能因为被包装成普通 io.Writer 而失去 ReaderFrom。外层接口变窄，io.Copy 的选择就会落回普通循环。

下面这个包装器故意只实现 Read，适合做一个最小复现实验。它的目的不是证明包装器一定慢，而是让快路径是否存在变成可观测事实。

type countingReader struct {
    r io.Reader
    n int
}

func (r *countingReader) Read(p []byte) (int, error) {
    n, err := r.r.Read(p)
    r.n += n
    return n, err
}

func copyOnce(src io.Reader, dst io.Writer) (int64, int) {
    counter := &countingReader{r: src}
    written, err := io.Copy(dst, counter)
    if err != nil {
        panic(err)
    }
    return written, counter.n
}

如果这是上传链路里的统计层，可以考虑把统计放在不改变快路径的具体类型上，或者明确接受普通循环的成本。不要为了“保留优化”随手给包装器补一个看似通用的 WriteTo，因为它必须正确处理目标 Writer 的错误和短写。

哪些场景适合保留快路径，哪些场景不必强求

文件到文件、内存缓冲区到文件这类大块连续复制，值得先确认快路径是否被包装器截断。它们的瓶颈通常不是几次函数调用，而是系统调用次数、内核缓冲和磁盘吞吐。

如果复制链路中必须做压缩、加密、内容哈希或限速，数据本来就要经过自定义处理，普通读写循环未必是主要成本。此时更应该测量 CPU、系统调用和下游等待时间，而不是只盯着 io.Copy 这三个字。

io.CopyBuffer 适合调用方需要统一缓冲区、或者要复用一块已经分配好的内存时使用。但官方规则仍然成立：两端命中 WriterTo 或 ReaderFrom 时，传入的 buffer 不会用于这次复制。

用基准测试确认是哪条路径在工作

最快的验证方式不是把 buffer 从 32 KB 改到 1 MB，而是给源端和目标端各放一个带计数的探针，再用同一份数据跑基准。探针只记录调用次数，不改变复制协议；测试完成后对比 WriteTo、ReadFrom 和 Read 的计数。

func BenchmarkCopyPath(b *testing.B) {
    data := bytes.Repeat([]byte("go-copy-"), 1024*128)
    b.SetBytes(int64(len(data)))
    for i := 0; i 

基准只适合比较路径和趋势，不能直接当成生产吞吐。要复现线上问题，还要把真实的文件大小、网络连接、TLS、磁盘和限速层带进测试，并记录 go test -bench . -benchmem 的结果。

常见问题：io.Copy 快路径怎么判断

把变量写成 io.Reader，会不会自动失去 WriterTo？

接口变量本身只暴露它声明的方法，但传入的动态值仍可能被类型断言识别。真正决定结果的是传给 io.Copy 的动态类型，以及中间是否经过只保留 Read 的包装器。

io.CopyBuffer 一定比 io.Copy 快吗？

不一定。命中 WriterTo 或 ReaderFrom 时，buffer 甚至不会参与；没有快路径时，才应该用基准测试比较不同缓冲大小。

给包装器实现 WriterTo 就能恢复速度吗？

只有在实现完全正确时才可以这样做。它必须把数据写入传入的 Writer，正确返回写入字节数和错误；如果还要统计、限速或校验，建议先写测试覆盖短写、读错误和写错误。

复制变慢时第一条命令该跑什么？

先用基准或探针确认调用路径，再用系统调用和资源指标判断瓶颈。只修改 buffer 大小而不确认是否命中快路径，通常是在调一个无效旋钮。

把排查结论带回上传链路

这类问题的落点不是“永远追求快路径”，而是把接口边界当成性能设计的一部分：需要透明统计时保留正确的能力，必须改写数据时接受额外处理，并用基准和生产指标验证取舍。下一次上传耗时异常，先看两端的动态类型和包装器，再决定是否调整缓冲区。