Go 问答：io.Copy 传输大文件时如何判断中途断开，错误和字节数怎么核对

用 io.Copy 把上传文件转存到对象存储或临时文件时，真正需要判断的不是“函数有没有返回”，而是返回的 written 是否达到预期、err 是否为空，以及源端是否给出了完整结束信号。中途断开通常会留下一个小于预期的字节数和一个可追溯的错误。

io.Copy 正常读到源端 EOF 时返回 err == nil；传输是否完整，要把 written、源文件大小和错误一起核对，不能只判断错误为空。

上传现场里，为什么只看 err 不够

假设接口收到一个 512 MiB 的文件，服务端把请求体写入 upload.part。如果客户端在 380 MiB 处断网，底层读取可能返回连接错误，io.Copy 会把已经写入的数量返回出来；如果源端正常结束，io.Copy 则把 EOF 当作完成条件，不会把 EOF 作为错误返回。

所以这段判断不能写成“err == nil 就把临时文件改名”。对于带 Content-Length 的上传，至少还要比较 written 和期望长度；对于本地源文件，还可以在复制前读取 src 的大小。

先把 io.Copy 的两个返回值分开看

written 是已经写入 dst 的字节数，err 是复制过程中遇到的第一个错误。正常复制到源端 EOF 时，错误是 nil，不是 io.EOF。

written, err := io.Copy(dst, src)
if err != nil {
    return fmt.Errorf("copy failed after %d bytes: %w", written, err)
}
fmt.Printf("copy completed: %d bytes\n", written)

这里的顺序很重要：错误日志要带上 written，否则同样的“传输失败”无法区分刚开始就断开，还是已经写入了大半文件。

用一个可控的 Reader 复现中途断开

网络连接不容易稳定复现，可以先用一个会在指定位置报错的 Reader 做单元测试。它刻意返回已经读取的字节数，同时给出 errDisconnected，这样能观察 io.Copy 如何保留已完成数量。

var errDisconnected = errors.New("source disconnected")

type cutReader struct {
    data []byte
    cut  int
    pos  int
}

func (r *cutReader) Read(p []byte) (int, error) {
    if r.pos >= r.cut {
        return 0, errDisconnected
    }
    n := copy(p, r.data[r.pos:r.cut])
    r.pos += n
    return n, nil
}

written, err := io.Copy(io.Discard, &cutReader{data: payload, cut: 380})
if !errors.Is(err, errDisconnected) || written != 380 {
    return fmt.Errorf("unexpected result: written=%d err=%v", written, err)
}

测试的可见结果是 written=380 且 errDisconnected 可被 errors.Is 命中。这个结果说明目标端已经接收了部分数据，临时文件不能当成完整文件继续使用。

完整性核对要绑定已知长度

如果源文件的长度已知，成功条件应当是“没有错误，并且 written == expected”。不要把“长度不符”包装成网络错误，它是独立的完整性失败，便于排查上游截断或协议字段不可信。

func copyExact(dst io.Writer, src io.Reader, expected int64) (int64, error) {
    written, err := io.Copy(dst, src)
    if err != nil {
        return written, fmt.Errorf("copy stopped at %d bytes: %w", written, err)
    }
    if written != expected {
        return written, fmt.Errorf("size mismatch: want=%d got=%d", expected, written)
    }
    return written, nil
}

对 HTTP 请求体，expected 可以来自已经通过上限检查的 Content-Length；对本地文件，使用打开前读取到的文件大小。未知长度的流不能凭空比较数字，应依赖协议中的完成标记、校验和或下游确认。

断开、短写入和 EOF 不是一回事

io.Copy 自身会处理正常 EOF，但不会替应用猜测“数据是不是应该更多”。如果底层 Reader 返回非 EOF 错误，复制会停止；如果 Writer 没有按约定报告短写入，标准库会以写入异常处理。固定长度数据结构在中途遇到 EOF 时，读取层还可能返回 io.ErrUnexpectedEOF，它表达的是“在应该完整的位置提前结束”。

因此日志至少记录四个值：源标识、期望长度（若有）、written、err。失败路径删除或隔离临时文件，重试前先确认源端是否支持从偏移继续；不要无条件从头重试大文件。

把结果验收写成一个小闭环

实际代码里可以按下面的顺序收口：复制时记录 written；非空错误直接失败；已知长度再比对数量；校验和通过后才把临时文件移动到最终路径；任一步失败都保留错误上下文并清理半成品。

这个闭环的价值在于，客户端断开、代理提前结束、磁盘写满和上游长度错误会落到不同证据上。下次遇到“文件偶尔损坏”，先看 written 与 err，比盯着一条笼统的上传失败日志更快。

相关问题

io.Copy 成功时应该判断 err == io.EOF 吗？

不应该。官方语义是正常读到 EOF 时返回 err == nil；判断 EOF 反而会把正常完成误记成异常。

未知长度的流怎么确认没有少数据？

使用协议层完成标记、总长度字段或校验和。只有字节流本身没有边界时，单靠 io.Copy 返回的数量无法证明业务数据完整。

为什么失败文件不能直接改名复用？

因为 written 只代表已写入的数量，不代表缺失部分可以被忽略。应先清理半成品，或在明确支持断点续传且校验通过时再继续。

总结

判断大文件传输是否完成，要同时看 io.Copy 的 written 和 err。正常 EOF 是成功分支；非 EOF 错误是中断证据；已知长度还必须做数量核对。把这三个判断放在临时文件提交之前，才能避免半个文件被当成成品。