Go log.Fatal 放在库代码里为什么会终止宿主程序

我第一次在一个可复用的 Go 包里看到 log.Fatal(err)，直觉是“把错误记下来，再让上层处理”。实际运行却是宿主程序立刻结束，HTTP 服务不再接收请求，命令行工具也拿不到返回值。原因很明确：log.Fatal 输出日志后会调用 os.Exit(1)，它控制的是整个进程，不是当前函数。

库代码不要用 log.Fatal 替调用方做进程决策。库应返回带上下文的 error；是否打印、重试、降级或退出，交给 main、命令边界或服务启动层。

为什么 log.Fatal 会直接结束宿主进程

log.Fatal 的名字容易让人把它当成“严重级别的 Printf”。但标准库文档给出的语义是：它相当于打印日志后调用 os.Exit(1)；Fatalf 和 Fatalln 也一样。库函数虽然只是在调用栈中执行了一次方法，退出动作却作用于承载它的整个进程。

这也是为什么下面的调用不会返回 err，main 中的下一行也不会执行：

package main

import "log"

func loadConfig() error {
	// 库函数里的致命日志会结束整个宿主进程，而不是返回给调用者。
	log.Fatal("配置文件不可读")
	return nil // 这行不会获得执行机会
}

func main() {
	// 调用方原本想自行决定重试、降级或退出码。
	_ = loadConfig()
	log.Println("启动服务")
}

另一个容易漏掉的副作用是清理逻辑。os.Exit 结束进程时，不会执行通过 defer 注册的清理函数。因此文件关闭、临时目录删除、指标上报、缓冲写入等动作都不能指望在 log.Fatal 之后完成。这里的重点不是“Fatal 永远不能出现”，而是它应只存在于拥有整个进程控制权的最外层。

库代码应该怎样把错误交还给调用方

改造时先把“记录错误”和“决定退出”拆开。库函数返回一个有上下文的错误，调用方根据错误类型选择处理方式；不要在库内部偷偷打印一次、上层再打印一次。

package config

import "fmt"

func Load(path string) ([]byte, error) {
	data, err := readFile(path)
	if err != nil {
		// %w 保留底层原因，让上层可以用 errors.Is 或 errors.As 判断。
		return nil, fmt.Errorf("读取配置 %q: %w", path, err)
	}
	return data, nil
}

在应用边界统一处理：

package main

import (
	"errors"
	"fmt"
	"log"
	"os"
)

func run() error {
	// 业务层只返回错误，不在可复用函数里退出进程。
	_, err := loadConfig("config.yaml")
	if err != nil {
		return err
	}
	return nil
}

func main() {
	if err := run(); err != nil {
		// 入口层拥有退出权，因此只在这里决定日志和退出码。
		if errors.Is(err, os.ErrNotExist) {
			log.Printf("配置缺失: %v", err)
			os.Exit(2)
		}
		log.Printf("启动失败: %v", err)
		fmt.Fprintln(os.Stderr, "请修正配置后重试")
		os.Exit(1)
	}
}

如果这是 HTTP 服务，处理方式通常不是 os.Exit，而是把错误转换成响应、指标或重试信号；如果是一次性 CLI，main 可以在最外层选择非零退出码。相同的库函数才能被这两种宿主安全复用。

哪些场景可以保留 Fatal，哪些场景应该拒绝

我会重点检查三件事：搜索依赖包和内部包中的 log.Fatal；查看它是否位于 main 或命令入口；再检查错误是否已经被包装成可判断的原因。把库里的 Fatal 机械替换成 log.Printf 也不够，因为它仍然会吞掉错误。正确改法是让函数签名携带 error，沿调用链返回，最后由边界统一处理。

相关问题

log.Fatal 和 panic 应该怎么选？

log.Fatal 直接调用 os.Exit(1)；panic 会展开调用栈并允许上层 recover。两者都不适合作为普通库错误返回的替代品。

为什么 defer 没有执行？

因为 log.Fatal 的退出路径是 os.Exit，不是从函数返回，也不是正常的 panic 展开；需要清理资源时应先显式返回错误。

测试库函数时如何避免测试进程被杀掉？

让被测函数返回 error，再用 errors.Is 或 errors.As 断言原因。若必须检查退出码，把退出行为放在单独的命令入口测试中，不要让通用库直接退出测试进程。