Go os.CreateTemp无论成功失败都清理临时文件的实践示例

我在临时导出文件的代码里最容易漏掉的不是 os.CreateTemp，而是失败路径的清理：文件创建成功后，写入可能失败，Close 也可能失败，函数还可能在中途提前返回。可靠的做法是把“拿到路径后登记删除”放在最早位置，再把文件关闭作为独立的收尾动作。这样成功和失败都会尝试删除临时文件，同时保留最先发生的业务错误。

先把临时文件的生命周期钉在函数内

os.CreateTemp(dir, pattern) 会在指定目录创建唯一临时文件；目录参数为空时使用系统临时目录，模式中的最后一个 * 会被随机字符串替换。官方文档还明确说明，文件何时删除由调用方负责。这里的“清理”至少包含两件事：Close 关闭文件描述符，Remove 删除文件名。

因此不要只写 defer f.Close() 就认为磁盘文件已经消失，也不要在创建成功前调用 f.Name()。创建返回错误时没有可供清理的文件；只有拿到有效的 *os.File 后，才登记它的路径。

成功失败都走同一条清理路径

下面这段代码把清理动作集中在一个具名函数里。写入失败时先保存错误，清理动作仍继续；关闭失败只有在前面没有错误时才成为返回错误，删除失败也遵循同一规则。

package main

import (
    "fmt"
    "os"
)

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

    // 创建成功后立刻登记路径，覆盖写入失败和提前返回。
    path := f.Name()
    defer func() {
        // 先关闭句柄，再删除路径；不覆盖前面已经发生的错误。
        if closeErr := f.Close(); err == nil && closeErr != nil {
            err = fmt.Errorf("关闭临时文件: %w", closeErr)
        }
        if removeErr := os.Remove(path); err == nil && removeErr != nil {
            err = fmt.Errorf("删除临时文件: %w", removeErr)
        }
    }()

    // 这里模拟把数据写进临时文件，真实业务可替换成编码或导出逻辑。
    if _, err = f.Write(data); err != nil {
        return fmt.Errorf("写入临时文件: %w", err)
    }
    return nil
}

这段写法的关键不是 defer 本身，而是命名返回值 err 让收尾函数能够补充关闭或删除错误。若业务错误已经存在，清理失败只应记录到日志或指标，不能把更有价值的第一现场替换掉。

把清理责任与业务结果分开检查

如果临时文件要交给另一个进程读取，不能在读取完成前删除；如果只在当前函数内完成上传、压缩或编码，则可以在收尾阶段删除。清理时还要注意：Windows 等平台可能要求先关闭句柄才能删除，所以示例把 Close 放在 Remove 之前。

如果程序需要保留失败现场，可以把 Remove 的错误写入结构化日志，并记录临时文件路径；不要为了“必删”而无条件忽略它。生产代码还应给临时目录设置容量和清理监控，避免权限、磁盘满或进程异常退出造成堆积。

常见问题

只用 defer f.Close() 能删除临时文件吗？

不能。Close 关闭打开的文件，文件名仍然存在；还需要对 f.Name() 调用 os.Remove。

为什么不直接 defer os.Remove(f.Name())？

可以作为简单兜底，但它无法表达关闭错误，也不方便按顺序保证先关句柄再删路径。需要可靠错误处理时，用一个收尾函数集中处理更清楚。

删除失败应该让接口失败吗？

取决于临时文件是否可能泄露敏感数据以及后续是否会堆积。至少要记录删除失败；若清理是安全或容量要求的一部分，就应将它作为返回错误或告警处理。

记住这条边界即可：CreateTemp 负责安全地创建并打开文件，业务代码负责使用它，Close 和 Remove 共同负责收尾。把路径登记放在创建成功后的第一时间，才能让失败分支和成功分支拥有同一套清理保障。