Go log.Fatal 为什么导致 defer 没有执行

我第一次遇到这个问题时，现场看起来像是 defer 失效了：错误日志已经打印，文件关闭、临时目录清理或连接释放却没有发生。真正的原因在于 log.Fatal 不是普通的错误返回，它会先写日志，再调用 os.Exit(1)；进程一旦被直接终止，defer 就没有执行机会。

官方资料：https://pkg.go.dev/log、https://pkg.go.dev/os、https://go.dev/src/log/log.go

先看 log.Fatal 到底做了什么

标准库文档对 Fatal 的定义很直接：它相当于先调用 Print，再调用 os.Exit(1)。源码中的 Fatal、Fatalf 和 Fatalln 也都沿着这条路径结束进程。因此，下面的 defer 不是“执行了但没有清理成功”，而是根本没有进入执行阶段。

func openConfig() {
    file, err := os.Open("config.yaml")
    if err != nil {
        log.Fatal(err) // 先写日志，再 os.Exit(1)，不会回到函数返回点
    }
    defer file.Close() // 只有函数正常返回或发生 panic 展开时才有机会执行
    useConfig(file)
}

这里还有一个容易忽略的细节：log.Fatal 出现在 defer 之后还是之前，都不能把它当成“触发清理”的开关。只要真正执行到 log.Fatal，进程退出语义就覆盖了后续清理路径。

为什么 defer 没有执行机会

defer 绑定的是函数退出过程。常规 return 会让当前函数按规则执行已经登记的 defer；panic 也会沿调用栈展开并触发 defer。os.Exit 则是进程级终止，它不等待当前函数返回，也不为其他 goroutine 展开清理逻辑。

所以排查时不要只盯着“defer 是否写在了打开资源之后”。更重要的问题是：资源拥有函数有没有机会返回？如果错误分支直接调用 log.Fatal，这个函数永远走不到返回清理点。

把错误交给拥有资源的函数处理

更稳妥的边界是：谁打开资源，谁负责在自己的函数里登记 defer；遇到错误时只返回 error。最外层的 main 负责打印错误和决定退出码，但不把仍由下层持有的资源交给 os.Exit 突然截断。

func run() error {
    file, err := os.Open("config.yaml")
    if err != nil {
        return fmt.Errorf("打开配置文件: %w", err) // 把故障交给上层判断
    }
    defer file.Close() // run 返回前完成资源清理
    return loadConfig(file)
}

func main() {
    if err := run(); err != nil {
        log.Printf("启动失败: %v", err) // 先记录结果，不在资源函数里 Fatal
        os.Exit(1)                      // run 已返回，自己的 defer 已有机会完成
    }
}

这个结构把三种责任拆开了：run 管资源生命周期，错误值负责跨函数传递，main 才拥有进程退出决定。若还需要刷新日志、等待后台任务或写入最终状态，也应在退出前完成，而不是把 log.Fatal 分散到可复用函数中。

goroutine 和可复用函数里更不该随手 Fatal

log.Fatal 影响的是整个进程，不是当前 goroutine。把它放进 HTTP handler、定时任务、库函数或后台 goroutine，调用方通常无法恢复，也无法保证自己登记的清理逻辑执行。可复用函数应该返回错误；应用最外层再根据错误类型决定记录、重试、降级还是退出。

• 库代码：返回带上下文的 error，不要替调用方结束进程。
• 资源代码：在拥有资源的函数里登记 defer，让所有返回路径共享清理逻辑。
• 主程序：集中处理最终退出码，并确认不再依赖尚未清理的资源。
• 后台任务：使用取消信号和完成通知结束工作，不要用 Fatal 代替 goroutine 的退出协议。

用这张清单定位 defer 被跳过的原因

常见问题

把 log.Fatal 改成 panic 就一定更好吗？

不一定。panic 会触发展开路径上的 defer，但它仍然是异常控制流。库函数通常应返回 error；只有确实需要让程序崩溃并由上层恢复或统一处理时，才考虑 panic。

在 main 里调用 os.Exit 也会跳过 defer 吗？

会。os.Exit 的规则不因调用位置改变。可以让负责资源的子函数先返回并完成清理，再由 main 在没有待执行清理时决定退出。

log.Print 后 return 能保留错误日志吗？

可以。常见做法是在资源拥有函数中返回错误，在外层用 log.Printf 记录；这样既保留诊断信息，也不把清理责任交给进程强退。