Go io.CopyBuffer 缓冲区多大才适合大文件复制

用 Go 复制几十 GB 的文件时，io.CopyBuffer 的缓冲区并不是越大越快。更稳妥的起点是保留标准库的 32 KiB 左右基线；只有在读写端确实会反复经过这块 buffer、并且基准测试证明它受益时，才把它调到 64 KiB、128 KiB 或更大。并发复制时，真正要算的是“单次 buffer × 同时任务数”，而不是只看一个任务。

官方文档：https://pkg.go.dev/io

先确认复制路径，而不是先改缓冲区

io.CopyBuffer(dst, src, buf) 的语义是“在需要时用这块 buffer 暂存数据”，不是承诺每次 Read 都从它走一遍。Go 官方 io 实现会先检查源是否实现 WriterTo，再检查目标是否实现 ReaderFrom；命中其中一种时，会调用对应方法完成复制，传入的 buffer 不参与这条路径。

因此，从 *os.File 复制到另一个文件时，先确认具体类型和实现，比盲目把 buffer 改成 1 MiB 更有价值。只有普通 Reader/Writer 路径需要中间缓冲时，buffer 大小才直接影响每轮读写的粒度。

从 32 KiB 基线逐步选择大小

不指定 buffer 时，标准库当前实现会准备约 32 KiB 的临时缓冲区；如果源是 io.LimitedReader 且剩余内容更小，还会按剩余长度缩小。这个基线适合先写出正确版本，再根据真实 I/O 路径调整，而不是把它当成所有磁盘、网络和压缩流的最佳值。

可以按下面的决策表开始：

例如需要复用一块缓冲区时，可以显式设置 64 KiB。下面的代码只表达复制逻辑，注释说明了参数、错误处理和资源清理；它不代表某个机器上的实测成绩。

package main

import (
    "io"
    "os"
)

func copyFile(dstPath, srcPath string) (int64, error) {
    // 源文件只负责读取，失败时直接返回，避免继续使用无效句柄。
    src, err := os.Open(srcPath)
    if err != nil {
        return 0, err
    }
    defer src.Close() // 函数结束时释放源文件描述符。

    // 64 KiB 是可测量的起始点，不是对所有设备都适用的固定答案。
    buf := make([]byte, 64*1024)
    dst, err := os.Create(dstPath)
    if err != nil {
        return 0, err
    }
    defer dst.Close() // 无论复制成功或失败，都关闭目标文件。

    // written 用于判断复制量；CopyBuffer 返回的错误必须继续交给调用方。
    return io.CopyBuffer(dst, src, buf)
}

把单次大小放进并发内存预算

如果服务同时处理 100 个复制任务，每个任务都独立持有 1 MiB buffer，光这些切片就可能占用约 100 MiB，还没有算文件描述符、网络缓冲和业务对象。更大的 buffer 只有在减少等待、提高有效吞吐时才值得保留；如果读写端本身很慢，增加内存只会让更多数据停在内存里。

工程上可以先给每个任务分配 32 或 64 KiB，再用固定输入、固定并发和相同设备做基准。记录总耗时、复制字节数、错误类型以及进程内存变化，比较 32 KiB、64 KiB、128 KiB 三组即可，不必从几十个尺寸开始猜。若吞吐变化很小，选择更小的值通常更容易控制峰值。

三个容易误判的边界

第一，make([]byte, 0) 不是“暂时不用 buffer”，而是非法的空 buffer，CopyBuffer 会 panic；不用时请传 nil。第二，CopyBuffer 返回的 written 是已经写出的字节数，不能因为目标文件看起来存在就忽略错误。第三，defer Close 只负责释放资源，不会替你处理写入关闭阶段可能出现的错误；对重要落盘场景，还应设计关闭错误的记录策略。

最终判断可以归纳为：先确认复制路径，再从 32 KiB 左右开始；需要复用时选 64 KiB 或 128 KiB 做对照；一旦并发上升，按总预算重新计算。没有基准证据时，不要仅凭“大文件”三个字把 buffer 扩到 MiB 级。

常见问题

io.CopyBuffer 的 buffer 越大，复制越快吗？

不一定。它可能减少部分读写轮次，但也可能受底层实现、缓存和并发影响；只有固定条件下的基准测试能说明是否值得。

文件复制应该传 nil 还是自己 make buffer？

先传 nil 完成正确实现即可。需要复用、限制内存或控制读写粒度时，再传一个非空切片。

为什么我传了 buffer 却看不到它生效？

检查源是否实现 WriterTo、目标是否实现 ReaderFrom；命中优化路径时，官方实现明确说明 buffer 不会用于复制。