Go 批量写文件如何控制内存：io.Copy、临时文件与原子重命名的落盘路径

批量导出日志、拼接归档文件时，最容易踩的坑不是磁盘空间，而是把所有内容先收进一个大切片。文件一大，进程内存会跟着输入长度一起涨，失败时还很难留下一个可继续使用的结果。更稳的做法是让输入通过 io.Copy 流进同目录临时文件，关闭成功后再用 os.Rename 替换目标文件。

控制内存的关键不是“少分配几次”，而是让数据始终经过流式路径；临时文件和原子重命名则负责把半成品隔离在正式文件之外。

先把“内存里拼完整文件”换成数据流

如果批量任务先调用 io.ReadAll，再一次性写入目标文件，峰值内存至少会受文件大小影响。对单个超大文件，问题尤其明显；对多个输入循环拼接时，旧切片还可能在扩容和垃圾回收之间短暂占着空间。

流式版本只需要一个固定大小的复制缓冲区。下面的 copyToTemp 不关心输入来自文件、压缩解码器还是网络响应，只依赖 io.Reader，所以业务层可以把“数据来源”和“落盘策略”拆开。

package export

import (
    "io"
    "os"
    "path/filepath"
)

func copyToTemp(src io.Reader, temp *os.File) error {
    _, err := io.Copy(temp, src)
    if err != nil {
        return err
    }
    return temp.Sync()
}

这里的链路是 src → io.Copy → temp。复制返回错误时不要继续执行后续替换；temp.Sync 也要被视为数据路径的一部分，因为它失败时，临时文件不能被当成已经可靠写完。

临时文件为什么必须和目标文件放在同一个目录

临时文件的职责是隔离半成品。把它放在目标文件同一目录，既方便权限继承和清理，也让后面的 os.Rename 处在同一个文件系统语义里。不要先写到系统临时目录，再假设跨文件系统重命名一定成功。

下面这段代码把关键动作收拢到一个函数：创建临时文件、复制输入、关闭文件，最后才替换目标。失败路径统一删除临时文件，正式文件不会被半截内容覆盖。

func WriteAtomically(target string, src io.Reader) (err error) {
    dir := filepath.Dir(target)
    temp, err := os.CreateTemp(dir, ".export-*")
    if err != nil {
        return err
    }
    tempName := temp.Name()
    defer func() {
        if err != nil {
            _ = os.Remove(tempName)
        }
    }()

    if err = copyToTemp(src, temp); err != nil {
        return err
    }
    if err = temp.Close(); err != nil {
        return err
    }
    return os.Rename(tempName, target)
}

这条状态路径可以概括为：os.CreateTemp 创建临时状态 → copyToTemp 写入并同步 → temp.Close 完成句柄收尾 → os.Rename 进入正式文件状态。任何中间错误都会回到“删除临时文件”，而不是触碰旧目标。

错误处理要覆盖复制、同步、关闭和替换

很多示例只检查 io.Copy，却忽略 Close 和 Rename。本地磁盘满、权限变化、文件系统异常，都可能在这些阶段暴露。尤其是关闭失败时，调用方不应得到“写入成功”的结论。

代码里的命名返回值让延迟清理能够判断最终结果，但不要把清理错误覆盖原始错误。删除只是收尾动作，真正应该返回的是复制、同步、关闭或重命名的失败原因。

批量任务里的三个边界

输入失败时不创建空的正式文件

输入读取过程中断，临时文件可以被删除；目标文件继续保留旧版本。这样下游读取者至少还能读到上一份完整结果。

目标文件已存在时先确认替换语义

os.Rename 的覆盖行为受操作系统和目标类型影响。若业务要求绝不覆盖，应该在替换前增加明确的存在性策略；若业务允许发布新快照，则要把“旧文件被替换”写进验收条件。

跨目录或跨文件系统时不要强行套用原子替换

原子替换的前提是临时文件和目标处在同一文件系统语义下。目录不一致时，宁可重新设计落盘目录和发布步骤，也别把跨设备移动错误吞掉。

用可见结果验收这条落盘路径

测试不要只断言函数返回 nil，还要检查目标文件内容、临时文件是否清理，以及输入中途出错时旧文件是否仍然完整。可以用一个返回前半段后报错的自定义 io.Reader，验证失败不会留下半份正式结果。

生产日志至少记录目标路径、复制字节数和最终阶段；不要记录整份文件内容。成功状态应发生在 os.Rename 返回 nil 之后，这样监控看到的“成功”才与读者能打开的文件一致。

总结：把写入和发布拆成两个状态

流式复制解决的是内存随文件增长的问题，临时文件解决的是半成品隔离，原子重命名解决的是正式路径的发布边界。三者组合后，批量写文件不再需要把完整内容搬进内存，也不会让读取方撞上正在增长的目标文件。

常见问题

为什么不直接写目标文件？

直接写会让读取方看到中间状态；任务失败时，旧文件也可能已经被截断。临时文件能把失败隔离开。

一定要调用 temp.Sync 吗？

是否需要把数据同步到稳定介质取决于业务的持久性要求。若成功意味着重启后也必须尽量保留，应该把同步纳入错误判断，而不是只看复制是否结束。