Go io.ReaderFrom 如何决定零拷贝路径：WriteTo、ReadFrom 与缓冲回退

线上导出接口把一个大文件写到响应体时，最容易误判的是“用了 io.Copy 就一定零拷贝”。更准确的说法是：io.Copy 会先检查源端的 WriterTo，再检查目标端的 ReaderFrom，两者都没有时才进入内部缓冲复制；快路径是否真的省掉了复制，还取决于具体实现。

想看清这条路径，先把 WriterTo、ReaderFrom 和 copyBuffer 当成三个可观测分支，再用一个计数器验证到底调用了谁。

一个上传接口为什么会走出三条复制路径

假设服务端把 *os.File 内容写入 http.ResponseWriter，调用代码通常只有一行：

_, err := io.Copy(w, file)

但这行代码并不等于固定的缓冲循环。io.Copy 在标准库里先看源值是否实现 io.WriterTo；没有时，再看目标值是否实现 io.ReaderFrom；最后才调用内部的 copyBuffer。因此，排查性能时不能只盯着调用点，还要确认接口方法集。

最小配方：用计数器观察 WriterTo 与 ReaderFrom

先定义一个只实现 io.Reader 的源和一个同时实现 io.Writer、io.ReaderFrom 的目标。目标的 ReaderFrom 内部继续调用源的 Read，这样可以把“目标接管了复制”与“数据完全不经过 Read/Write”区分开。

package main

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

type target struct {
    writes, reads int
}

func (t *target) Write(p []byte) (int, error) {
    t.writes++
    return len(p), nil
}

func (t *target) ReadFrom(r io.Reader) (int64, error) {
    buf := make([]byte, 8)
    for {
        n, err := r.Read(buf)
        t.reads++
        if n > 0 {
            if _, werr := t.Write(buf[:n]); werr != nil {
                return 0, werr
            }
        }
        if err == io.EOF {
            return 0, nil
        }
        if err != nil {
            return 0, err
        }
    }
}

func main() {
    dst := &target{}
    _, err := io.Copy(dst, strings.NewReader("golang"))
    fmt.Println(err, dst.writes, dst.reads)
}

这里的关键不是计数器数值，而是 ReadFrom 是否进入。运行后，目标对象的 reads 会增加，说明 io.Copy 把控制权交给了目标端；如果目标没有 ReadFrom，同样的数据就会由 copyBuffer 读取并写出。

实现 ReaderFrom 时，EOF 和部分写入不能省略

ReaderFrom 不是“把 Read 调几次”的快捷别名。每轮要先处理 n > 0 的有效数据，再判断错误；因为一个合法的 Read 可能同时返回数据和 io.EOF。写入端也可能只接受部分字节，真实实现应继续处理剩余片段，而不是直接把本轮当作完成。

另一个边界是错误传播：目标的 ReaderFrom 返回的错误会直接成为 io.Copy 的结果。不要为了“走快路径”吞掉源读取错误，也不要把普通错误改成 io.EOF，否则上层只能看到一个看似成功的短文件。

WriterTo 优先意味着什么

如果源端实现了 io.WriterTo，它会先于目标端的 ReaderFrom 被调用。这个顺序会影响你给目标类型添加的优化：即使目标已经实现 ReaderFrom，只要源端先命中 WriterTo，目标方法就不会接管本次复制。

因此，给自定义类型增加接口前，先用一个小型探针记录调用路径。文件、缓冲区、网络连接等标准库类型的具体方法集可能随版本和包装层变化，经过 bufio.Writer、限速器或统计包装后，原有快路径也可能消失。

常见问题：这算不算真正的零拷贝

io.Copy 会自动调用操作系统的 sendfile 吗？

不能只根据 io.Copy 这一行下结论。标准库的某些文件到网络连接组合可能在更深层使用平台优化，但接口分发本身只保证优先尝试 WriterTo 或 ReaderFrom。是否进入内核级路径，要看具体类型和平台实现。

为什么加了 ReaderFrom，Write 计数却还是变化？

因为你的 ReaderFrom 可能在内部调用了 Write，这表示目标接管了循环，不表示完全跳过了用户态写入。要验证分支，应该同时记录 ReaderFrom 是否进入、Read 次数和实际写入字节数。

什么时候直接使用 io.CopyBuffer？

当需要控制缓冲区复用、内存上限或测试确定的读写批次时，可以使用 io.CopyBuffer。但它仍会先尝试 WriterTo 和 ReaderFrom；想改变接口分发，应该先检查包装类型，而不是只替换缓冲区。

把复制路径变成可验证的工程检查

最终建议保留一个小探针：分别准备只实现 Reader 的源、实现 WriterTo 的源和实现 ReaderFrom 的目标，记录三种情况下的入口方法、读取错误和写入字节数。这样升级 Go 版本或替换包装器后，性能判断仍然有证据，而不是把“io.Copy 等于零拷贝”当成经验结论。