Go io.Copy 为什么复制零字节文件没有报错

Go 的 io.Copy 遇到正常 EOF 就结束复制，并把这种结束报告为 err == nil。因此，源文件确实是零字节时，返回 n == 0、err == nil 是正常行为。它表示本次没有复制字节、也没有遇到需要报告的复制错误，不代表源文件满足“必须有内容”的业务要求。

如果你确信文件有内容，却得到同样结果，重点要查当前读取位置、实际传入的 Reader，以及此前是否已经消费了它。io.Copy 从当前状态继续读，不会自动把文件回到开头。下面以一个假设的附件归档故障为例：任务标为成功，但结果为空；这个场景用于讲解，不是实际事故记录，代码预期也不是本机运行结果。

Go 官方地址：https://go.dev/

影响面：复制成功和附件有效是两件事

归档任务如果只检查 err，空附件就会被标成成功。对允许空文件的备份系统，这完全合理；对必须有内容的报告上传，则需要额外判断 n。更严格的业务还可能要求内容能解析、字段齐全，这些都超出 io.Copy 的职责。

先还原调用关系：EOF 为什么没有变成错误

单次 Read 返回 EOF，是告诉调用方输入结束。io.Copy 的任务本来就是一直搬到输入结束，所以它把正常 EOF 吸收为成功结束；返回的 n 则保留搬移数量。把“没有数据”强制理解成读取故障，会误判合法的空文件。

这里要确认参数方向：copy 的目标 dst 在前，来源 src 在后。如果来源是 io.LimitReader 且限制为零，它可以直接表现为结束，即使底下真正的文件有内容。包装器描述的是本次可见输入，而不是磁盘文件的总大小。

触发条件：文件有内容，但位置已经在末尾

下面创建一个临时文件，分别说明空文件、写入后未重新定位、重新定位后三种情况。为了观察内容，目标采用 bytes.Buffer，不会覆盖已有业务文件。写入一个文件后，文件偏移会随写入移动，随后直接复制未必还剩可读数据。

package main

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

func run() error {
    f, err := os.CreateTemp("", "copy-state-*.dat")
    if err != nil {
        return fmt.Errorf("创建临时文件: %w", err)
    }
    name := f.Name()
    defer os.Remove(name) // 删除顺序在关闭之后，由 defer 的后进先出保证。
    defer func() {
        if err := f.Close(); err != nil {
            fmt.Fprintln(os.Stderr, "关闭临时文件:", err)
        }
    }()

    var dst bytes.Buffer
    n, err := io.Copy(&dst, f)
    if err != nil {
        return fmt.Errorf("复制空文件: %w", err)
    }
    fmt.Println("空文件复制字节数:", n)

    // 写入推进当前位置，文件有内容不代表当前位置还有内容。
    if _, err := f.WriteString("draft"); err != nil {
        return fmt.Errorf("写入样例: %w", err)
    }
    n, err = io.Copy(&dst, f)
    if err != nil {
        return fmt.Errorf("从当前位置复制: %w", err)
    }
    fmt.Println("末尾位置复制字节数:", n)

    // 普通可定位文件需要明确回到开头，错误不能忽略。
    if _, err := f.Seek(0, io.SeekStart); err != nil {
        return fmt.Errorf("回到文件开头: %w", err)
    }
    dst.Reset()
    n, err = io.Copy(&dst, f)
    if err != nil {
        return fmt.Errorf("重新定位后复制: %w", err)
    }
    fmt.Printf("重新复制: %d %q\n", n, dst.String())
    return nil
}

func main() {
    if err := run(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1) // run 已经返回，内部 defer 有机会完成。
    }
}

按这些操作推导，前三次复制的字节数分别为 0、0、5，最后目标内容是 draft。第二次为零与空文件不是同一原因：文件大小已经增加，但当前位置在末尾。将示例保存为 main.go 后可自行运行观察；临时文件在函数退出时关闭并清理。

Seek 只适用于支持定位的对象。管道、网络输入以及一般 io.Reader 不能一律回绕。若此前为了探测或计算摘要已经读过数据，应在调用设计中明确复用方式：普通文件重新打开或定位，流式输入则保留探测到的前缀并与剩余输入组合，不能指望 io.Copy 替你恢复已经消费的内容。

修复动作：把非空要求写成业务判断

如果附件必须包含至少一个字节，保留返回的 n，在复制错误处理之后判断它。下面的辅助函数只约束非空，不承担打开、关闭和删除目标的责任；其输入从当前位置开始，调用方负责准备正确的 Reader。

func copyRequired(dst io.Writer, src io.Reader) (int64, error) {
    n, err := io.Copy(dst, src)
    if err != nil {
        // 出错时可能已经写入部分字节，向调用方保留计数。
        return n, fmt.Errorf("复制附件: %w", err)
    }
    if n == 0 {
        return 0, fmt.Errorf("附件内容为空，不符合本次归档要求")
    }
    return n, nil
}

这个函数片段需要 fmt 和 io。业务若允许空文件，就不应照搬非空限制。已知必须精确复制某个字节数时，可以使用具有固定数量契约的 io.CopyN，并单独处理来源不足；这与无固定长度的 io.Copy 是不同目标。也不要把 n > 0 当成格式正确：一个只有空白的文本同样可能复制成功。

防止复发：记录数量、输入归属和目标收尾

对这个故障，日志至少要能区分“复制零字节”与“复制发生错误”。在任务记录里存实际 n、输入来源类型以及必要的任务标识，比只写“成功”更有用。普通文件可以结合元数据辅助排查，但大小不能单独证明本次复制应有多少字节：当前位置、并发修改和包装器限制都可能改变可读范围。

目标若是 bufio.Writer，io.Copy 结束后还需要 Flush 并处理错误；目标若是自己打开的文件，也要处理关闭错误，是否调用 Sync 由持久化需求决定。io.Copy 不会替调用方关闭两端。如果失败后不能留下半成品，应先写独立的临时目标，业务接受且收尾成功后再发布结果，失败则清理自己创建的临时目标。实际替换已有文件还需要按平台和业务约束设计。

还要排除源和目标指向同一个文件的情况。尤其不要先用 os.Create 打开已有源路径作为目标，再期待原内容仍然可读；创建目标的截断行为可能已经让源变空。示例使用内存目标，正是为了隔离这类与 EOF 无关的破坏性因素。

相关问题

返回 nil 是否说明复制完成了原文件的全部内容？

只能说明本次 src 所暴露的输入正常复制结束。起始位置在中间、包装器限制长度或者输入已经被消费，都可能只复制部分甚至零字节。

CopyBuffer 能修复零字节复制吗？

不能靠换缓冲区恢复已经耗尽的输入。它改变缓冲策略，不改变来源当前状态与正常 EOF 的含义。

读不到数据但也没有 EOF，会立刻成功吗？

不要把返回 0、nil 的单次 Read 当作输入结束。自定义 Reader 应遵守接口约定；持续无数据又不结束的实现可能导致复制没有进展，这与合法空文件直接到达 EOF 不同。

参考：io.Copy 与复制返回值、io.CopyN、os.File.Seek。