Go io.WriterTo 怎样让源端直接写入目标并减少中间缓冲

如果一个 Go 的源对象本来就知道怎样把自己的数据写给目标，那么让它实现 io.WriterTo，再交给 io.Copy，通常比强迫它暴露成一轮轮 Read 更贴合数据结构。io.Copy 会先检查源端是否实现了 WriterTo，命中后直接调用 src.WriteTo(dst)；只有源端没有这项能力时，才会再看目标端的 io.ReaderFrom，最后才落到普通缓冲复制。

官方地址：https://pkg.go.dev/io#WriterTo

这不是“实现一个接口就必然更快”的口号。真正值得做的前提是：源端能提供更自然的块结构、能正确处理短写和错误，而且包装层不会把这项接口能力悄悄抹掉。

io.Copy 为什么会优先看源端

io.WriterTo 的方法只有一个：WriteTo(w io.Writer) (n int64, err error)。它把写入方向交给源端，由源端决定怎样组织数据、怎样复用已有缓冲，以及怎样把每次写入的数量累加起来。官方实现把它放在 io.Copy 的第一判断位置，并明确说明这样可以避免一次分配和一次拷贝。

这个优先级带来一个重要判断：如果源端和目标端同时拥有优化接口，源端的 WriterTo 先被采用。不要只给目标类型增加 ReadFrom，然后假设它一定能接管复制；调用方传入的源对象可能已经改变了选择结果。

什么时候值得让源端实现 WriteTo

适合实现 WriterTo 的源对象，通常有一个稳定的内部数据组织方式，例如分块消息、已经切好的帧、压缩器输出片段或可顺序消费的缓存。源端可以直接把当前块写入目标，少一次把数据拼成临时大缓冲的动作。

不适合的情况也很明确：数据必须经过复杂变换才知道下一段内容、写入目标会改变源端的并发语义，或者源端没有办法在失败后说明已经写出了多少。接口很小，契约却不小；它不是把 Read 方法改名就完成了。

WriteTo 的实现，重点是短写和错误

下面的示例用分块源模拟一个可顺序消费的数据对象。它同时保留 Reader 能力，方便在没有走快路径的场景下仍有普通读取接口；WriteTo 则直接面对目标 Writer。示例是文章参考代码，没有在本任务中运行。

package streamcopy

import "io"

type blockSource struct {
    blocks [][]byte
    index  int
    offset int
}

func (s *blockSource) Read(p []byte) (int, error) {
    // Reader 只负责提供兼容路径，保留当前块的未读偏移。
    for s.index  0 {
            return n, nil
        }
    }
    return 0, io.EOF
}

func (s *blockSource) WriteTo(w io.Writer) (written int64, err error) {
    // 源端按现有数据块写出，避免先拼接成一个临时大切片。
    for s.index 

这里的关键不是 WriteTo 里是否出现了循环，而是每次 Write 的返回值都被认真处理：目标端返回非空错误就停止；只写了一部分却没有错误，就返回 io.ErrShortWrite；成功写完一个块后才推进源端状态。这样调用方拿到的 written 才能解释已经交给目标多少字节。

包装、ReaderFrom 和并发是三个反例

第一，包装类型可能改变接口集合。比如自定义包装器只嵌入了 io.Reader，却没有继续暴露 WriteTo，那么同一个底层源被包一层后，io.Copy 可能回到普通缓冲路径。需要保留快路径时，应明确设计包装器是否转发该方法，而不是依赖偶然的类型推断。

第二，目标端的 ReaderFrom 不是强制接管权。只要源端实现 WriterTo，目标端的同名优化就排在后面。第三，源对象包含可推进的 index 和 offset，这通常意味着它不是并发安全的共享游标。不要让多个 goroutine 同时对同一个源调用 Read 或 WriteTo，除非类型自己定义并实现了同步规则。

落地前用这份清单做判断

可以把决定压缩成五个问题：源端是否有稳定的块或分段结构？是否能明确报告写入数量？目标短写是否会被识别？包装层是否需要转发 WriterTo？源端状态是否只由一个消费者推进？五个问题都能回答，再考虑用 io.Copy 暴露这条路径。

实现 WriterTo 后，io.CopyBuffer 还会使用我传入的缓冲区吗？

不一定。官方实现说明，只要源端实现了 WriterTo 或目标端实现了 ReaderFrom，提供给 CopyBuffer 的缓冲区不会用于执行复制。

WriteTo 返回 EOF 才算正常结束吗？

不需要。正常写完应返回已写字节数和 nil；io.Copy 的成功语义本来就不是把 EOF 当作错误返回。

只想优化一个调用点，还要实现整个 Reader 吗？

如果对象只在一个受控接口中使用，可以直接设计面向目标的写出方法；但要接入通用 io.Copy，仍应同时满足 io.Reader 与 io.WriterTo 的边界，并写清状态和并发约束。

参考资料：https://pkg.go.dev/io#WriterTo、https://pkg.go.dev/io#Copy、https://go.dev/src/io/io.go。两张图片均为原创静态结构说明图，不是截图或运行证据。