Go os.File.ReadFrom 如何影响文件复制：ReaderFrom 快路径与短读处理

复制大文件时，很多 Go 代码会直接写成 io.Copy(dst, src)。这行代码看起来没有选择项，但真正决定写入路径的，是目标对象是否提供了 io.ReaderFrom；对 *os.File 来说，这个方法就是 ReadFrom。理解这层分派关系，才能解释为什么同样是复制，替换目标类型后行为可能不同。

把文件复制到 *os.File 时，优先让 io.Copy 发现目标的 ReadFrom；遇到自定义 Reader 的短读或非 EOF 错误，再用返回的字节数和错误值判断是否需要保留部分结果。

先看 io.Copy 到底选择了谁

io.Copy 的调用方只提供源和目标，但标准库会先观察接口能力。目标实现 io.ReaderFrom 时，复制逻辑可以把“从 Reader 读取并写入目标”的责任交给目标；否则才会落回通用缓冲复制。os.File.ReadFrom 的公开文档明确写着它实现了 io.ReaderFrom。

src, err := os.Open("input.bin")
if err != nil {
    return err
}
defer src.Close()

dst, err := os.Create("output.bin")
if err != nil {
    return err
}
defer dst.Close()

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

这段代码的关键不是“有没有手写缓冲区”，而是 dst 的动态类型。如果它是 *os.File，调用链可以落到 os.File.ReadFrom；如果目标只是一个没有 ReaderFrom 的 io.Writer，则由 io.Copy 走通用路径。两种路径都遵守 ReaderFrom 的结果语义，但内部是否使用平台能力要由目标平台和标准库实现决定。

ReaderFrom 快路径不等于忽略错误

io.ReaderFrom 的约定是从 Reader 读到 EOF 或错误，返回已经读取的字节数。io.EOF 表示正常结束；其他错误必须继续向调用方报告。因而下面的判断比“复制后再看文件是否存在”可靠得多：

n, err := dst.ReadFrom(src)
switch {
case err == nil:
    log.Printf("copied=%d", n)
case errors.Is(err, io.EOF):
    log.Printf("copied=%d, reached eof", n)
default:
    return fmt.Errorf("read from source after %d bytes: %w", n, err)
}

实际使用中，ReadFrom 通常会把正常 EOF 处理成 nil，但调用者仍应保留对“字节数加错误”的处理习惯。特别是自定义 Reader 可能先返回一段数据，再返回短读、网络错误或校验错误；部分文件已经写入时，错误不能被吞掉。

另一个容易混淆的点是“短读”。Reader 一次只返回少量字节是允许的，只要它继续被调用，复制就可能正常完成。只有当后续错误不是 io.EOF 时，才应把这次复制视为失败。

三个场景怎么选实现

目标就是本地文件

优先使用 io.Copy，让目标的 ReadFrom 自己决定可用路径。这样代码表达的是复制意图，也不会把某个平台的系统调用细节硬编码到业务层。

目标是带审计的自定义 Writer

如果 Writer 需要逐块记录审计、限速或加密，先确认它是否实现了 io.ReaderFrom。没有实现时，io.Copy 会使用通用写入；贸然给它加一个不完整的 ReadFrom，反而可能绕过原本的审计逻辑。

源来自网络或校验流

把非 EOF 错误当成失败，并记录 n。如果业务允许断点续传，应由上层明确处理临时文件、校验和以及重试位置，不要把“目标文件已经变大”误当成完整成功。

用一个可控 Reader 验证边界

可以写一个每次只返回 3 个字节的 Reader，观察复制是否会因为短读而提前结束。测试重点是最终字节数和文件内容，不是某一次 Read 返回了多少。

type chunkReader struct {
    data []byte
    pos  int
}

func (r *chunkReader) Read(p []byte) (int, error) {
    if r.pos == len(r.data) {
        return 0, io.EOF
    }
    count := min(3, len(r.data)-r.pos)
    copy(p, r.data[r.pos:r.pos+count])
    r.pos += count
    return count, nil
}

如果 Reader 最终返回 io.EOF，io.Copy 应返回完整字节数和 nil。若把最后一次读取改为返回自定义错误，则测试应断言错误仍然可见，同时目标中已经写入的前缀仍与返回的 n 对应。

常见问题

io.Copy 一定会调用 os.File.ReadFrom 吗？

只有目标的动态类型实现了 io.ReaderFrom 时，才具备这条接口路径。具体内部优化仍取决于标准库版本和运行平台。

短读是不是复制失败？

不是。短读只说明本次读取返回的数据少，后续仍可能继续读取；要结合最终错误和累计字节数判断。

为什么不能只判断 err == nil？

发生非 EOF 错误时，目标可能已经写入部分数据。记录 n 能帮助日志、临时文件清理和断点续传做出正确决定。

收尾检查

文件复制的最小可靠检查可以归纳成三件事：让 io.Copy 根据真实目标类型选择路径；把 io.ReaderFrom 当作带明确语义的接口而不是神秘加速开关；在错误分支同时记录 n 和 err。这样即使源从本地文件换成网络 Reader，验证方式也不会失效。