Go 临时文件句柄未关闭怎样排查资源泄漏

Go 临时文件句柄泄漏，优先查三件事：CreateTemp 成功后谁负责 Close，defer 所在函数何时返回，以及 Remove 是否只删除路径却遗漏了句柄。把单个任务拆成短函数，并在同一所有者里分别处理关闭与删除，通常比增加清理定时器更直接。

下面以批处理暂存文件为例，说明资源回收设计及排查依据，不虚构已发生的生产事故或实测数据。官方地址：https://go.dev/。代码使用 errors.Join，要求 Go 1.20 或更新版本。

批处理越跑越慢时，先区分句柄与路径

设想一个常驻任务逐份暂存输入，处理结束后继续下一份。如果临时目录越来越大，首先说明路径残留值得检查，不能单凭文件数量断言句柄泄漏；如果进程的打开文件资源不断增长，则应结合任务并发数、打开与关闭记录查明归属。二者可以同时发生，也可能只有一种。

CreateTemp 返回的文件已经打开。Close 结束对这个文件对象的使用，Remove 清理名字对应的目录项，两者不是同一个动作。删除名字不能代替关闭仍持有的文件对象；反过来，关闭对象也不代表临时路径已清理。不同系统对打开文件删除的限制不同，本文统一采用先关闭再删除的回收约定。

把临时目录和清理权限交给明确的所有者

临时文件应写在任务运行身份有权限使用的目录中。可以把专用临时目录作为 dir 参数显式传入，便于配置和定位；传空字符串则使用系统临时目录。文件名用模式生成，不用用户输入直接拼接成待删除路径。排查时记录任务标识和必要的路径标识，避免把敏感文件内容写入日志。

调用关系要有清楚约定：创建者拥有文件对象，消费回调只借用它，不能关闭、重命名、删除或在函数返回后继续异步使用。若组件必须接管文件，就要明确转移所有权，并修改清理方案；不能让两层都认为“另一层会关闭”。示例使用当前任务独占的路径，不覆盖已有文件，也不扫描清理别人的目录。

每个任务单独结束资源生命周期

最容易遗漏的并不是没写 defer，而是把它放在整个批次函数的循环里。defer 随所在函数返回而执行，不在每次循环结束时执行。批次持续很久时，所有已打开文件可能都要等到批次结束才关闭；这属于生命周期过长，即便最后能释放，也会造成运行期间资源压力。

把每份输入交给 ProcessOne，所有返回路径共同经过同一个清理闭包。源读取器 src 由调用者拥有，示例不替调用者关闭它；consume 必须同步完成。如下片段可作为独立包中的实现，并非本机执行记录。

package tempjob

import (
    "errors"
    "fmt"
    "io"
    "os"
)

// ProcessOne 独占本次临时文件；consume只借用文件，不得关闭或异步保留。
func ProcessOne(dir string, src io.Reader, consume func(*os.File) error) (err error) {
    f, err := os.CreateTemp(dir, "job-*.tmp")
    if err != nil {
        return fmt.Errorf("创建临时文件: %w", err)
    }
    name := f.Name() // 保存本次创建的确切路径，不清理通配目录。
    defer func() {
        // 显式按关闭、删除的顺序尝试；每种错误分别留在返回链中。
        if closeErr := f.Close(); closeErr != nil {
            err = errors.Join(err, fmt.Errorf("关闭临时文件: %w", closeErr))
        }
        if removeErr := os.Remove(name); removeErr != nil {
            err = errors.Join(err, fmt.Errorf("删除临时路径: %w", removeErr))
        }
    }()

    if _, err := io.Copy(f, src); err != nil {
        return fmt.Errorf("写临时文件: %w", err)
    }
    if _, err := f.Seek(0, io.SeekStart); err != nil {
        return fmt.Errorf("重置读取位置: %w", err)
    }
    if err := consume(f); err != nil {
        return fmt.Errorf("消费临时文件: %w", err)
    }
    return nil // 返回前执行清理，清理失败也会改变最终返回值。
}

外层串行循环每次调用结束后再处理下一项，就不会把本次文件的清理延迟到整个批次末尾。并行执行则需要同时限制在途任务数；每个任务即使都正确关闭，也仍可能因瞬时并发过大而用尽资源。不要用“没有永久泄漏”推导“不会资源耗尽”。

把关闭与删除列为独立完成条件

资源完成条件应独立于内容处理成功：输入复制成功、读取位置调整成功、回调结束，都只是主处理阶段；关闭和路径删除仍可能失败。示例在命名返回值 err 上合并清理错误，让调用者得到真实的最终状态，而不是只返回回调的 nil。

清理规则属于应用代码的任务完成设计，不要求用额外校验器扫描文件。排查已有代码时，可以沿每个成功创建点查正常返回、提前返回和消费失败分支，确认都能到达同一回收位置。

失败时保留原始错误和清理错误

如果写入失败后又出现删除失败，不能用最后一个错误覆盖最初原因。errors.Join 保留多个错误，包装时分别写明阶段，上层可用 errors.Is 或 errors.As 查错误链。日志展示可能包含多行，结构化系统中更适合把任务和阶段单独记录，不只靠搜索一条英文字符串。

关闭失败后，示例仍尝试删除，并保留两种错误；它不宣称已回收成功，也不自动重试 Close。已经关闭的 File 再次 Close 会报错，不能为了保险在多个层次随意重复关闭。若回调私自关闭，最终清理会暴露这个契约违规，而不是悄悄把它算成正常结束。

深层辅助函数不要直接调用 os.Exit 或 log.Fatal 来代替返回错误，否则进程退出会绕过尚未执行的 defer。让辅助函数返回，等本次清理完成，再由最上层决定退出、继续还是告警。突然终止、崩溃和断电也不属于 defer 能保证覆盖的情形，遗留文件回收需要独立且范围明确的运维策略。

用任务记录复盘，而不是等待垃圾回收

复盘时先看每批任务的创建数、完成数、在途数与清理失败数，再与进程打开文件资源的趋势对照。它们不是简单相减就能精确等于系统句柄总数，因为进程还持有日志、连接和其他文件。应把相同任务的创建和回收关联起来，避免把正常长连接或当前在途任务当成临时文件泄漏。

目录已经空了，为什么还要查 Close？

目录反映的是名字，不是进程所有打开对象。继续查持有者和关闭记录，不要只重复删除路径。

能否让垃圾回收帮忙关闭？

不要把资源预算押在不可预测的回收时机上。明确的 Close 才能把文件生命周期与任务边界绑定，仍可达的对象更不能指望靠 GC 及时回收。

异常退出留下的文件怎样处理？

只处理本服务拥有且能确认不再使用的遗留项，建立任务状态和保留策略；不要根据文件名包含 tmp 就执行宽范围删除。当前示例只删除本次成功创建的确切路径，不包含后台扫描器。

最后的判断不是“代码里有没有 defer”，而是“资源由谁拥有、何时结束、失败能否被看见”。短函数收敛生命周期，关闭与删除分别计账，再把清理失败带回调用者，才能使批处理长期运行时的资源行为可解释。

参考：os 临时文件与关闭接口、Go defer 语言规则、errors.Join 接口。