Go 临时文件没有清理怎样避免磁盘增长

Go 的临时文件不会因为函数返回就自动从磁盘消失。os.CreateTemp 创建并打开文件，os.MkdirTemp 创建临时目录，但删除文件或目录的责任仍在调用方。服务如果只调用了 Close，只是释放文件描述符，路径对应的磁盘空间还会保留；如果只在成功分支删除，写入失败和提前返回也会留下垃圾文件。

避免磁盘增长的关键，是在临时资源创建成功后立刻绑定清理动作：单个文件通常用 defer os.Remove(f.Name())，临时目录用 defer os.RemoveAll(dir)；清理动作要覆盖错误路径，并在需要时记录清理错误。

• 创建文件后先记住路径，关闭文件和删除路径是两件事。
• 写入、解析或上传失败时，也必须经过同一个清理出口。
• 一组临时文件放在独立目录时，优先删除目录而不是逐个猜文件名。
• 长时间运行的服务还要确认临时目录位置、命名模式和历史遗留处理方式。

临时文件增长通常从哪里开始

我在处理导入、压缩和中转任务时，最容易忽略的是“创建成功”本身已经产生了一个文件系统对象。os.CreateTemp 返回的是可读写的 *os.File，文件名可以通过 Name 取得；传入空目录时，Go 会使用系统默认临时目录。这个 API 解决的是安全地创建唯一临时文件，不替业务决定什么时候清理。

因此，下面两件事要分别看待：

创建成功后立即绑定文件清理

单个临时文件最稳妥的写法，是在检查创建错误后马上登记删除动作。这样后续无论写入失败、解析失败还是业务提前返回，函数退出时都会执行清理。defer 只负责调用删除函数，所以文件仍应在结束前显式关闭。

package main

import (
    "fmt"
    "os"
)

func preparePayload(data []byte) error {
    f, err := os.CreateTemp("", "payload-*.tmp")
    if err != nil {
        return fmt.Errorf("创建临时文件: %w", err)
    }

    // 创建成功后立刻登记删除，覆盖写入失败和提前返回路径。
    path := f.Name()
    defer func() {
        // Close 负责释放文件描述符，Remove 负责删除磁盘路径。
        _ = f.Close()
        _ = os.Remove(path)
    }()

    if _, err := f.Write(data); err != nil {
        return fmt.Errorf("写入临时文件: %w", err)
    }
    if err := f.Close(); err != nil {
        return fmt.Errorf("关闭临时文件: %w", err)
    }

    // 真实业务可以在这里完成读取、解析或上传，返回前由 defer 清理。
    return nil
}

示例把路径保存到局部变量，避免在清理函数里重复推导文件名。若临时文件需要交给后续步骤使用，可以把清理责任放到拥有完整生命周期的上层函数，而不是在生产者刚返回时就删除；最重要的是责任只有一个明确的拥有者。

写入失败和提前返回也要经过清理

只在最后一行调用 os.Remove 是常见遗漏。任何可能返回错误的操作都可能让最后一行无法执行，尤其是写入、编码、解压和上传。把清理绑定在创建成功后的作用域里，能让错误路径和正常路径共用同一份资源释放逻辑。

func writeAndPublish(data []byte) error {
    f, err := os.CreateTemp("", "publish-*.tmp")
    if err != nil {
        return fmt.Errorf("创建中转文件: %w", err)
    }
    path := f.Name()

    // 清理函数同时处理关闭和删除，确保错误返回不会留下文件。
    defer func() {
        _ = f.Close()
        _ = os.Remove(path)
    }()

    if _, err := f.Write(data); err != nil {
        return fmt.Errorf("写入中转文件: %w", err)
    }
    if err := f.Close(); err != nil {
        return fmt.Errorf("关闭中转文件: %w", err)
    }

    // 这里继续做上传或解析；任一步返回错误都会触发上面的清理。
    return nil
}

这里的 defer 忽略了清理错误，适合“清理失败不应覆盖主错误”的简单场景。若清理失败本身会影响重试、合规或容量管理，就应把清理函数改成命名返回值或显式收集错误，并把路径写入日志，方便后续人工处理。

临时目录要用 RemoveAll 收口

当一次任务会产生多个中间文件时，我更倾向于先建立一个独立临时目录，再把目录作为资源边界。这样不需要在多个分支里维护文件清单，也不容易把同名文件误删。os.MkdirTemp 返回目录路径；任务结束后由调用方负责移除整个目录。

func buildArchive(input []byte) error {
    dir, err := os.MkdirTemp("", "archive-work-")
    if err != nil {
        return fmt.Errorf("创建临时目录: %w", err)
    }
    // 目录拥有本次任务产生的全部中间文件，退出时统一删除。
    defer func() {
        _ = os.RemoveAll(dir)
    }()

    partPath := filepath.Join(dir, "part.bin")
    if err := os.WriteFile(partPath, input, 0600); err != nil {
        return fmt.Errorf("写入分片: %w", err)
    }
    // 后续可以在 dir 内继续生成其他中间文件；任一分支返回都会清理整个目录。
    return nil
}

目录清理的目标必须来自刚刚成功创建的路径，不能把用户输入直接拼成 RemoveAll 的参数。对于需要保留产物的任务，应在清理前把最终文件移动到明确的持久化目录，临时目录只承载中间状态。

长时间运行服务如何处理历史遗留

新代码绑定 defer 只能保证新请求的生命周期，不能自动删除已经遗留在系统临时目录里的旧文件。服务上线后可以把临时资源统一放入带有稳定前缀的目录或文件名，并让后台维护任务按业务状态清理；维护任务需要限制目录范围、记录失败项，避免把其他进程的临时文件当成自己的资源。

排查磁盘持续增长时，先确认程序实际使用的临时目录，再按应用前缀观察文件数量和最后修改时间。不要把“文件描述符数量下降”当成“磁盘空间已经释放”：前者对应 Close，后者还需要删除路径。若进程仍持有文件，某些系统上的删除行为和可见空间回收还可能不同，资源所有权和平台语义都要纳入部署方案。

常见问题

调用 Close 后临时文件为什么还在？

Close 只关闭文件，不删除路径。需要在文件生命周期结束时调用 os.Remove(f.Name())，或由拥有该资源的上层统一清理。

os.CreateTemp 失败时需要 Remove 吗？

如果创建函数返回错误，通常没有可供调用方使用的文件对象和路径；应保留创建错误并返回。只有创建成功后，才登记对应的清理动作。

多个临时文件怎样避免漏删？

为一次任务创建独立临时目录，把中间文件都放入目录，结束时使用 os.RemoveAll 删除目录。最终产物需要保留时，先移动到持久化目录。

清理失败要不要覆盖原始业务错误？

取决于业务。普通任务可以记录清理失败而保留主错误；容量、合规或重试依赖清理结果时，应显式收集两类错误并记录临时路径。