Log.Fatal 一调即停是因为它内部调用 os.Exit(1)，绕过 defer、清理逻辑和后续代码；适用于无资源需释放的 CLI 初始化等场景，长服务应改用信号监听+优雅关闭。
Log.Fatal 为什么一调就停？
Log.Fatal 不是普通日志，它内部调用 os.Exit(1)，绕过 defer、runtime cleanup、甚至 main 函数后续逻辑。哪怕你前面写了 defer closeDB()，它也完全不执行。
常见错误现象：
- 服务启动时配置加载失败，
log.Fatal("config: ", err)一出，连接池没关、监听端口没释放、临时文件残留 - 单元测试里误用
log.Fatal，导致整个测试进程中断，无法捕获错误或继续跑其他 case - 在 goroutine 中调用，看似“只杀自己”，实则直接终结整个进程（Go 没有线程级退出）
这不是日志级别问题，是控制流劫持 —— 它根本不是“记录错误”，而是“宣布死刑”。
用 log.Printf + os.Exit 替代 Log.Fatal 的实操要点
想保留“记录+退出”语义，但要可控，就拆开两步：
立即学习“go语言免费学习笔记（深入）”；
说明：先打日志（用 log.Printf 或 log.Error），再显式调用 os.Exit，这样你能插在中间做清理。
实操建议：
-
os.Exit前加defer注册的函数不会执行，所以清理动作必须写在os.Exit之前 - 错误码建议统一：非 0 表示异常退出，比如
os.Exit(1)（通用失败）、os.Exit(2)（配置错误）、os.Exit(3)（依赖不可用） - 如果项目用了
log/slog，对应用slog.Error+os.Exit，别混用log.Fatal和slog
if err != nil {
log.Printf("failed to load config: %v", err)
cleanup() // 显式清理，比如关闭 logger、释放锁、关闭监听器
os.Exit(2)
}优雅退出的核心：注册信号 + 控制主循环
Log.Fatal 的真正替代方案，不是换一个日志函数，而是放弃“遇到错就死”的思维，改用“收到信号才退”的机制。
使用场景：
- HTTP server、gRPC server、消息消费者等长运行服务
- 需要等待正在处理的请求完成再退出（避免 502/超时）
- 要保证 metrics 上报、trace flush、日志刷盘
实操建议：
- 用
signal.Notify监听os.Interrupt（Ctrl+C）和syscall.SIGTERM（k8s kill、systemd stop） - 主逻辑放在
select循环里，接收退出信号后设标志位，不再接受新请求，等待 in-flight 工作完成 - 别在 signal handler 里直接调
os.Exit—— 它会跳过所有收尾逻辑
sigChan := make(chan os.Signal, 1) signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM) <!-- ... 启动 server --> <!-- ... 启动 worker pool --> <!-- ... 启动 metrics ticker --> <p><!-- 等待退出信号 --> <!-- 收到后调 shutdown()，再 os.Exit(0) -->
log.Fatal 在哪些地方其实可以留着？
不是所有地方都要“优雅”。有些场景下，Log.Fatal 是合理且最简选择：
- CLI 工具的初始化阶段：比如解析命令行参数失败、读不到必需 flag，此时没状态要清理，
log.Fatal清晰直接 - 测试辅助函数（非测试主体）：比如
mustOpenFile这类 helper，本意就是“出错就崩，别往下走”，只要不在TestXxx函数体里直接用就行 - 临时脚本、一次性迁移工具：没有长期资源、无并发、无外部依赖，用
log.Fatal反而少写三行
关键判断点：有没有需要释放的资源？有没有正在运行的 goroutine？退出是否影响外部系统？
如果全是否，那 log.Fatal 就不是 bug，是 feature。
真正的复杂点不在怎么替换 Log.Fatal，而在于——你得先理清楚自己的程序有哪些资源要管、哪些信号要响应、哪些请求算“in-flight”。没人能替你画那张 shutdown 依赖图。
