Go io.Copy 为什么没有使用自定义缓冲区

我第一次给 io.Copy 换缓冲区时，最容易误判的一点是：只要把 []byte 传给 io.CopyBuffer，这块内存就一定会参与读写。实际情况恰好相反，Go 会先看接口是否提供更直接的复制方法。只要源实现了 WriterTo，或目标实现了 ReaderFrom，自定义缓冲区就会被绕过。

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

要让自定义缓冲区生效，先确认复制双方没有走 WriterTo/ReaderFrom 快路径；普通业务优先保留快路径，需要控制缓冲区时再用只暴露 Read/Write 的适配器隔离它。

这个判断来自 io 包公开契约和当前实现：Copy 没有缓冲区参数，CopyBuffer 才允许调用方提供缓冲区，但它不会强行关闭接口优化。

我先看的是 Copy 的分派顺序

io.Copy(dst, src) 的顺序可以压缩成三层。第一层检查 src.(io.WriterTo)，成功就调用 src.WriteTo(dst)；第二层检查 dst.(io.ReaderFrom)，成功就调用 dst.ReadFrom(src)；两者都没有时，才进入读一块、写一块的普通循环。

因此，同样是文件复制，目标是文件、连接或其他带有 ReadFrom 的实现时，路径可能和一个只实现 io.Writer 的包装器完全不同。这里的“没有使用自定义缓冲区”不是参数失效，而是复制已经交给更具体的实现决定。

CopyBuffer 只控制回退路径

CopyBuffer 的作用是“如果需要缓冲，就使用我提供的 buf”，而不是“无论如何都使用 buf”。官方文档还给了两个边界：buf == nil 时由函数分配临时缓冲区；len(buf) == 0 时会直接 panic。

当前 Go 源码的普通回退路径默认按约 32 KiB 建立缓冲区；如果源是 io.LimitedReader，还会按剩余字节数缩小它。这属于实现细节，不能把 32 KiB 当成 API 承诺。真正影响结果的边界仍是“是否存在快路径”和“调用方是否明确传入 buf”。

想让缓冲区真正生效要先处理快路径

如果业务确实要统一缓冲区大小、复用一块内存，或者想把复制行为纳入自己的压测模型，可以给读写端套一个只暴露基础方法的适配器。适配器不改变原对象的资源生命周期，只让传给 CopyBuffer 的动态类型不再声明 WriterTo 或 ReaderFrom。

package main

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

// plainReader 只暴露 Read，避免把底层 Reader 的 WriterTo 方法带入接口断言。
type plainReader struct{ r io.Reader }

func (p plainReader) Read(buf []byte) (int, error) {
	return p.r.Read(buf)
}

// plainWriter 只暴露 Write，避免让底层 WriterFrom 快路径参与本次复制。
type plainWriter struct{ w io.Writer }

func (p plainWriter) Write(buf []byte) (int, error) {
	return p.w.Write(buf)
}

func main() {
	src := bytes.NewBufferString("把自定义缓冲区接入普通复制路径")
	var dst bytes.Buffer
	buf := make([]byte, 8) // 复用这块缓冲区，长度必须大于 0

	// 适配后只剩 Reader/Writer，CopyBuffer 才会使用 buf。
	n, err := io.CopyBuffer(plainWriter{w: &dst}, plainReader{r: src}, buf)
	if err != nil {
		panic(err) // 生产代码应按业务返回或记录错误
	}
	fmt.Printf("写入 %d 字节：%s\n", n, dst.String())
}

这个例子的关键不是“8 字节一定更快”，而是把控制权边界写清楚：适配器让 CopyBuffer 看到的双方只有 Read/Write，所以自定义 buf 会进入普通循环。若底层对象需要 Close，仍然要保存并关闭原始文件或连接，不能把适配器当成资源管理器。

我的判断清单

• 只想完成文件、连接或管道复制：先用 io.Copy，不要为了“看见缓冲区”主动破坏快路径。
• 必须指定缓冲区：用 io.CopyBuffer，并检查源端 WriterTo 与目标端 ReaderFrom 是否让它绕过 buf。
• 必须强制普通循环：使用只实现 Read/Write 的适配器，同时保留原始资源的关闭责任。
• 排查结果时关注返回的字节数和第一个非 EOF 错误；成功复制返回 err == nil，不是 io.EOF。

相关问题

io.CopyBuffer 传入 nil 会怎样

它会在需要普通缓冲路径时自行分配临时缓冲区；如果双方存在 WriterTo 或 ReaderFrom，仍然不会使用这块临时缓冲区。

为什么自定义缓冲区大小没有带来性能提升

最常见原因是调用没有进入缓冲循环，或瓶颈在网络、磁盘和对端实现。先确认动态类型和快路径，再用同一输入、同一目标、相同错误处理方式做压测，避免只比较 buf 大小。

所以，io.Copy 没有“使用自定义缓冲区”的根本原因，是它的 API 设计把缓冲区留给回退实现，同时优先尊重 WriterTo 与 ReaderFrom。理解这个顺序后，保留快路径还是隔离快路径，就能成为一个明确的工程选择。