io.Copy 复制为空文件因未正确打开目标文件或源已到 EOF;须用 os.O_CREATE | os.O_WRONLY | os.O_TRUNC 打开目标,检查 io.Copy 返回的 n > 0 且 err == nil;大文件复制应先定位 I/O 瓶颈,再考虑用 io.CopyBuffer 自定义缓冲区。
因为 io.Copy 不会自动关闭目标文件,也不处理源文件读取失败后的状态。常见错误是打开目标文件用了 os.O_CREATE 但没加 os.O_WRONLY 或 os.O_TRUNC,导致写入失败却无报错。更隐蔽的问题是:源文件句柄已到 EOF(比如被其他 goroutine 读过一遍),io.Copy 立即返回 0, nil,看起来“复制成功”实则没写入任何内容。
正确做法:
Seek(0, 0) 可用(如需多次复制)os.O_CREATE | os.O_WRONLY | os.O_TRUNC 打开io.Copy 返回的 n, err 必须检查:err == nil 且 n > 0 才算有效复制io.Copy 默认使用 io.CopyBuffer 内部的 32KB 缓冲区,对 GB 级文件足够,但若遇到 I/O 延迟高或磁盘吞吐低的环境,小缓冲会导致系统调用频繁、CPU 耗高。此时不应盲目增大缓冲区,而应优先确认瓶颈是否在磁盘或文件系统(如 NFS 挂载点)。
可控优化方式:
立即学习“go语言免费学习笔记(深入)”;
io.CopyBuffer(dst, src, make([]byte, 1 设置 1MB 缓冲(注意:不能超过 1GB,否则分配失败)
io.Copy 复制多个小文件——改用 os.ReadDir + 单次 os.OpenFile 批量处理典型场景是用 http.Get 获取资源后,直接把 resp.Body 传给 io.Copy,但忘记 defer resp.Body.Close() ——看似没问题,实则当 io.Copy 遇到网络中断或服务端提前断连时,底层连接会被关闭,后续再读就会触发该错误。
安全写法必须包含三要素:
context.WithTimeout 控制请求生命周期io.Copy 后立即 resp.Body.Close()(不能 defer,因为要等 copy 完)io.Copy 返回的 err:若为 net.ErrClosed 或 io.ErrUnexpectedEOF,说明传输不完整resp, err := http.DefaultClient.Do(req)
if err != nil {
return err
}
defer resp.Body.Close() // 注意:这是对 resp 的 defer,不是对 Body 的
f, err := os.Create("out.bin")
if err != nil {
return err
}
defer f.Close()
n, err := io.Copy(f, resp.Body)
if err != nil && err != io.EOF {
return fmt.Errorf("copy failed: %w", err)
}
if n == 0 {
return errors.New("no bytes copied, check HTTP status or network")
}
从 os.Stdin 或 os.Pipe 复制数据时,io.Copy 会在读到 EOF 后自然退出,但容易忽略两点:一是 os.Stdin 在终端中按 Ctrl+D 才发 EOF,脚本中若期望“读完就停”,需配合 bufio.Scanner;二是管道写端未关闭前,io.Copy 会一直阻塞。
典型陷阱:
cmd.StdoutPipe() 获取 reader,但父进程未调用 cmd.Wait(),导致 pipe 写端悬空,io.Copy 永不返回io.Copy(ioutil.Discard, r) 丢弃流时,若 r 是带超时的 net.Conn,可能因读超时返回 net.OpError,需区分处理/dev/stdin 复制时,若输入来自重定向(./a ),io.Copy 行为正常;但若来自管道(echo x | ./a),某些 shell 会提前关闭 fd,需加 os.Stdin.Stat() 判断是否为 pipe
io.Copy 不校验数据完整性,也不保证
原子性**。复制中途崩溃,目标文件就是半截垃圾。真要可靠,得自己加 checksum 或用 os.Rename 配合临时文件。