从 io.Reader 到 io.WriterTo：Go I/O 抽象为什么这么耐用

Go 标准库里有些接口小到近乎朴素，io.Reader 就是典型代表。它只有一个 Read 方法，却贯穿文件、网络、压缩、加密、HTTP 请求体、命令行管道和内存缓冲区。

很多开发者第一次接触时会觉得它过于简单，真正写到工程代码里才会发现：越小的接口，越容易被组合，也越不容易过时。Go I/O 的耐用性，正来自这种“最小接口 + 可选增强”的设计。

小接口稳定，组合更灵活

io.Reader 的定义非常克制：

type Reader interface {
    Read(p []byte) (n int, err error)
}

调用方只关心一件事：把数据读进 p 这个缓冲区，并返回实际读取的字节数。数据来自文件、TCP 连接、字符串、压缩流还是对象存储 SDK，调用方完全不需要知道。

这类代码不绑定文件路径，也不绑定网络连接。只要传入的对象实现 Read，它就能工作。接口越小，调用方越不容易被具体类型绑住。

Go I/O 也很强调组合。io.Reader 负责读，io.Writer 负责写，io.Closer 负责关闭。需要多个能力时，再组合成更具体的接口：

type ReadCloser interface {
    Reader
    Closer
}

HTTP 请求体的类型是 io.ReadCloser，意思很明确：它既能读，又需要关闭。字符串读取器不需要 Close，网络连接需要；只读流不需要 Write，双向连接需要。每个类型只实现自己真正拥有的能力，调用方按场景声明最小需求。

io.Copy 不只是循环读写

很多开发者会把 io.Copy 理解成“创建一个缓冲区，然后循环读写”。这个理解不算错，但只说了一半。

基础模型类似下面这样：

for {
    n, readErr := src.Read(buf)
    if n > 0 {
        if _, err := dst.Write(buf[:n]); err != nil { return err }
    }
    if readErr == io.EOF { break }
    if readErr != nil { return readErr }
}

真实的复制代码还要处理短写等边界。更关键的是，标准库的 io.Copy 会先检查更高效的路径：如果源对象实现了 WriterTo，就调用 src.WriteTo(dst)；否则，如果目标对象实现了 ReaderFrom，就调用 dst.ReadFrom(src)。

WriterTo 的定义也很小：

type WriterTo interface {
    WriteTo(w Writer) (n int64, err error)
}

它表达的意思是：这个数据源知道如何更高效地把自己写出去。比如 bytes.Buffer、bytes.Reader、strings.Reader 这类内存数据源，内部已经知道剩余数据在哪里，可以减少通用复制逻辑带来的额外开销。

可以用一个小实验观察 io.Copy 的选择：

type src struct{ *strings.Reader }

func (s src) WriteTo(w io.Writer) (int64, error) {
    fmt.Println("src.WriteTo")
    return s.Reader.WriteTo(w)
}

当 src 实现 WriteTo 后，执行 io.Copy(dst, src) 会优先进入 src.WriteTo。如果源对象没有这个能力，io.Copy 才会继续检查目标对象是否实现 ReadFrom。

可选接口让性能自然升级

WriterTo 和 ReaderFrom 的设计很克制。普通类型只需要实现 Read 或 Write 就能接入生态；性能敏感的类型再额外实现可选接口。调用方不用改代码，io.Copy 会自动识别。

这就是 Go I/O 抽象耐用的核心：基础接口保持稳定，高级能力通过小接口渐进增强。

业务代码通常只需要声明最小依赖：

func save(dst io.Writer, src io.Reader) error {
    _, err := io.Copy(dst, src)
    return err
}

save 可以把 HTTP 请求体写入文件，也可以把内存数据写入响应，还可以把压缩流写入对象存储。函数签名没有变化，使用场景却能自然扩展。

同样的思路也适用于哈希、压缩、加密、上传和下载。函数接收 io.Reader，调用方就可以传文件、HTTP Body、字符串 Reader，也可以传测试里构造的内存数据。可测试性和复用性都来自同一个原则：依赖行为，不依赖来源。

边界比技巧更重要

写自定义类型时，不要一开始就急着实现所有接口。先实现最基础的 Read 或 Write，保证语义正确；如果性能分析发现复制成为瓶颈，再考虑补充 WriteTo 或 ReadFrom。

实现这些接口时要格外注意返回值语义。n 必须表示实际传输的字节数，错误也要如实返回。为了追求优化而破坏语义，会让 io.Copy、压缩库、HTTP 处理链出现难以排查的边界问题。

Reader 是流式抽象，不代表可以重复读取。读过的数据通常就消费掉了，除非底层类型支持 Seek，或者业务主动保存一份副本。HTTP Body 只能读一次，就是这个语义的直接体现。

另外，Read 返回 n > 0 的同时也可能返回非空错误。调用方应该先处理已经读到的数据，再处理错误。io.Copy 的优化路径也不是魔法，它不会替业务解决限流、超时、取消和内存上限。

写在最后

Go I/O 抽象耐用，不是因为接口多，而是因为接口足够小。io.Reader 和 io.Writer 提供最稳定的公共语言，io.Closer、io.WriterTo、io.ReaderFrom 等小接口在需要时补充能力。

这种设计让简单类型容易接入，让复杂类型有优化空间，也让业务代码长期保持稳定。真正值得借鉴的不是某一个接口本身，而是背后的工程原则：先用最小抽象表达行为，再用可选能力承载性能。