Go 大文件转存怎么选：io.ReadAll、io.Copy 与流式校验的边界

订单归档服务要从合作方拉一份 ZIP 文件，测试环境只有几百 KB，直接 io.ReadAll 后再写磁盘很顺畅。到了生产，某次文件变成 1.8 GB，进程内存先被撑高，操作失败后还留下一个看似完整的半截文件。这里真正要选的不是“哪个函数更快”，而是文件大小是否已知、是否必须先整体检查、以及失败后能不能把脏文件挡在正式目录之外。

对大多数线上大文件转存场景，优先走流式写入路径，提前设好读取上限、落盘走临时文件校验完成后再改名，是兼顾内存稳定和数据准确性的通用方案。

先按文件大小和后续动作划分场景

io.ReadAll 会把 Reader 的全部内容放进一个 []byte。它不是不能用于文件，而是特别适合“拿到完整内容后立刻做 JSON 校验、签名核对或很小的模板处理”这类明确受限的场景。若来源没有可靠大小、内容可能很大，或者目标本来就是磁盘、对象存储上传流，那么把所有字节先放进内存，通常是在给峰值内存埋雷。

这里别急着根据 Content-Length 下结论。它可能缺失，也可能是 -1；它适合做早期拒绝，却不能替代实际读取时的上限校验。更稳的做法是：有长度就先挡一次，读流时再挡一次。

为什么整读后写文件会在大文件场景失控

把响应内容读成切片后再调用 os.WriteFile，代码很短，但一个文件会同时占用响应缓冲和字节切片两段内存。并发拉取三份文件时，峰值内存不是单文件大小的简单叠加，很容易超出服务的内存预留值。更麻烦的是，出现网络中断时，错误点离正式落盘动作很近，团队容易只记下“下载失败”，却没有记录已经写了多少字节。

// 只适合大小明确且很小的内容。
limited := io.LimitReader(resp.Body, 1 1

上面这段的重点不是 1 MiB 这个具体数字，而是上限必须来自业务约束。配置快照可以很小，客户导出的历史 CSV 则完全不是同一个量级。遇到后者，把“先整体读完”改成“边读边写”更符合它的用途。

用 io.Copy 让响应体直接流向临时文件

io.Copy 会从 Reader 持续读取并写给 Writer，直到读到结束或发生错误，并返回已复制的字节数。对远端文件转存来说，目标 Writer 就是一个临时文件；返回的 written 则是很实用的核对数据。官方文档还说明，某些 Reader 或 Writer 自己带有更高效的复制路径，因此不要为了猜测缓冲大小而过早把所有调用改成手写循环。

func saveRemoteFile(ctx context.Context, url, finalPath string, maxBytes int64) (int64, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return 0, err
    }
    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return 0, err
    }
    defer resp.Body.Close()

    if resp.StatusCode != http.StatusOK {
        return 0, fmt.Errorf("unexpected status: %s", resp.Status)
    }
    if resp.ContentLength > maxBytes {
        return 0, fmt.Errorf("declared file is too large")
    }

    tempPath := finalPath + ".part"
    f, err := os.Create(tempPath)
    if err != nil {
        return 0, err
    }
    defer f.Close()

    written, err := io.Copy(f, io.LimitReader(resp.Body, maxBytes+1))
    if err != nil {
        return written, err
    }
    if written > maxBytes {
        return written, fmt.Errorf("stream exceeds limit")
    }
    return written, os.Rename(tempPath, finalPath)
}

这段代码里有两个容易漏掉的边界。第一，ContentLength 只做前置判断，实际流还要经过 io.LimitReader；第二，正式文件只在复制和长度检查成功后才出现。实际项目还应在返回错误时清掉 .part 文件，避免下次任务把残留误当成可用结果。

需要摘要校验时，不要再把文件读一遍

有的接口会在响应头或任务元数据里给出 SHA-256。常见的低效写法是先落盘，再打开文件算一次哈希；文件大时这等于把磁盘重读了一遍。更简洁的方式是用 io.MultiWriter 同时把字节写进临时文件和哈希对象。它和 io.Copy 放在一起，正好把下载、落盘、计数和校验收在同一条路径里。

sum := sha256.New()
target := io.MultiWriter(file, sum)
written, err := io.Copy(target, io.LimitReader(resp.Body, maxBytes+1))
if err != nil {
    return err
}
if written > maxBytes {
    return fmt.Errorf("stream exceeds limit")
}
actual := hex.EncodeToString(sum.Sum(nil))
if !strings.EqualFold(actual, expectedSHA256) {
    return fmt.Errorf("sha256 mismatch")
}

校验顺序也有取舍：若来源给的是可信摘要，核对通过再改名最稳；若来源没有摘要，至少记录 written、响应状态和生成时间，并根据业务格式做一次解析或解压测试。不要把“复制函数返回 nil”理解成文件内容一定符合业务预期。

选择表：哪种写法更适合你的任务

• 需要整体 JSON 解析：使用 io.ReadAll，并在 Reader 前加限制；读取后立刻校验结构，不要把数据长期挂在内存里。
• 附件、报表、归档文件：使用 io.Copy 写临时文件，关注 written、响应状态和清理动作。
• 高并发批量转存：除了流式复制，还要限制同时进行的任务数；单个任务省内存，不代表总并发没有压力。
• 需要可追溯性：在复制过程中同步计算摘要，成功后再原子改名，并把摘要和长度写进任务记录。

io.CopyBuffer 适合你确实要复用一块受控缓冲区、并且已经通过压测确认它有价值的情况。普通转存先用 io.Copy 即可；文档说明某些实现会走自身的快速路径，此时你传入的缓冲区未必参与复制。先把大小上限、临时文件和核对做对，收益往往比执着于缓冲区大小更实在。

常见问题

io.Copy 成功后还需要检查 Content-Length 吗？

需要。若服务端给出了非负长度，可以比较它和 written；但缺失或未知长度并不罕见，所以流式上限与业务格式校验仍不能省。

临时文件改名一定是原子的吗？

通常只有源和目标位于同一文件目录或同一文件挂载范围时，改名才具备你期望的替换语义。跨目录搬运前要确认部署环境的文件规则，不要把它当成无条件保证。

为什么不直接相信文件扩展名？

扩展名只是名称的一部分，不能证明内容格式。ZIP、CSV 或图片等场景应结合响应类型、长度、摘要以及业务可接受的解析检查判断。

读流中断后要怎么处理？

记录已写入字节和错误原因，删除临时文件；若上游支持断点续传，再由明确的任务状态决定是否从指定位置继续，不要把残留文件直接当成下一次的输入。

把内存边界和文件状态一起设计

io.ReadAll 与 io.Copy 没有谁绝对更高级：前者适合受控的小内容，后者适合把大字节流稳稳送到目标位置。真正决定稳定性的，是读取上限、临时文件、长度或摘要核对，以及失败后不让半成品进入正式路径。把这几个动作放在同一条转存链上，后面的排查会轻松很多。