Go os.CreateTemp 如何避免临时文件泄漏：关闭、重命名与失败清理

程序把配置写入临时文件后崩在半路，最麻烦的往往不是这次请求失败，而是临时目录里不断累积残留文件，文件描述符也跟着上涨。用 Go 的 os.CreateTemp 写安全替换逻辑时，要把“文件已创建”“内容已写入”“句柄已关闭”和“临时文件已删除”当成四个不同的状态。

os.CreateTemp 返回打开状态的文件；成功路径要先完成 f.Close() 再 os.Rename，失败路径则应尽早执行 os.Remove(f.Name())。创建成功不等于清理责任已经完成。

先把临时文件的生命周期分开

os.CreateTemp(dir, pattern) 会创建并打开一个临时文件；目录参数为空时，Go 会使用 os.TempDir() 返回的默认目录，模式在 umask 之前为 0600。文件名由 pattern 和随机后缀组成，pattern 中最后一个星号会被随机字符串替换。

这里有一个容易被忽略的事实：返回值是 *os.File，所以文件已经打开。调用方需要同时记住 f.Name() 和 f.Close()。前者服务于路径操作，后者负责释放打开的文件描述符；两者不能互相代替。

安全替换配置文件的最小写法

下面的函数把内容写入同一目录中的临时文件，关闭成功后再替换目标文件。临时文件和目标文件放在同一目录，是为了避免把 os.Rename 变成跨文件系统操作。

func replaceConfig(path string, data []byte) (err error) {
    dir := filepath.Dir(path)
    f, err := os.CreateTemp(dir, ".config-*.tmp")
    if err != nil {
        return err
    }

    tmp := f.Name()
    defer func() {
        if err != nil {
            _ = os.Remove(tmp)
        }
    }()

    if _, err = f.Write(data); err != nil {
        _ = f.Close()
        return err
    }
    if err = f.Close(); err != nil {
        return err
    }
    return os.Rename(tmp, path)
}

这段代码里有三条真实路径：os.CreateTemp 生成临时文件，f.Name() 记录它的路径，最后由 os.Rename 把已关闭的临时文件提交为目标文件。任何中途返回错误的路径，都会通过 os.Remove 尝试清掉临时文件。

失败路径为什么还要显式清理

不要只写一个 defer f.Close() 就认为资源管理完成。关闭句柄和删除路径解决的是两类问题：f.Close() 释放打开状态，os.Remove 清理目录项。写入失败、关闭失败和重命名失败时，三者都可能需要关注。

示例中的命名返回值 err 让清理 defer 能判断最终结果。写入失败时先显式调用 f.Close()，随后返回并触发 os.Remove；关闭失败则不再执行 os.Rename，同样由 defer 清理；只有关闭成功，才把 Rename 当作提交动作。

上线前检查目录、权限和替换边界

临时目录不是抽象概念。目录不存在或当前用户没有写权限时，os.CreateTemp 会直接失败；默认目录还会受运行环境的 TMPDIR 等配置影响。生产代码更适合把临时文件放在目标文件同目录，并在启动检查中确认目录可写。

os.Rename 也不是跨平台的事务提交协议。它适合在同一文件系统内完成路径替换，但不能替代应用级备份、权限复查和崩溃恢复设计。若目标是重要配置，提交前可以记录旧文件是否存在，提交后再用 os.Stat 检查目标路径。

几个看似省事的写法会留下什么问题

只关闭，不删除

文件描述符可能及时释放，但临时目录项仍会留下。服务长期运行时，这种小残留会变成磁盘清理任务和排障噪声。

先 Rename，再 Close

这会让“提交”发生在文件仍处于打开状态时，行为还会受到操作系统语义影响。把 f.Close() 放在 os.Rename 前面，成功条件更容易审计。

临时文件放到系统临时目录

如果目标文件位于另一个挂载点，重命名可能不再是同一文件系统内的简单替换。安全写入配置时，优先使用目标目录并用部署环境实测。

用故障注入验证清理结果

不要只测正常写入。可以让目标目录暂时不可写、让写入数据返回错误，或在测试中替换文件系统抽象，分别观察返回错误、临时文件数量和目标文件内容。验收标准是：失败返回可识别，目标文件不被半截内容覆盖，临时文件在函数返回后不再残留。

如果清理本身失败，示例选择忽略 os.Remove 的错误，是因为它不能覆盖原始写入错误；生产日志应记录临时路径和清理错误，方便后续人工回收，但不要把临时路径直接作为用户可控的 HTML 内容输出。

总结：把 Rename 当提交，把 Remove 当回滚

一套可维护的 os.CreateTemp 写入流程可以压缩成一句话：同目录创建，保存 f.Name()，写入后执行 f.Close()，关闭成功才调用 os.Rename；任何失败都尝试 os.Remove。这套顺序不解决所有存储一致性问题，却能先把句柄泄漏、临时残留和半截替换这三个常见坑隔开。

相关问题

为什么不直接用 os.WriteFile？

简单覆盖文件时可以用它；需要写入临时文件、检查结果后再替换时，os.CreateTemp 让中间状态有了明确路径和清理点。

关闭失败后还能 Rename 吗？

不建议。关闭失败说明文件状态或底层写入结果还没有被可靠确认，应保留错误并走 os.Remove 清理路径。