os.Exit会跳过所有defer，这是Go运行时明确设计而非bug；它绕过函数返回路径，导致defer全不执行，仅适用于配置加载失败等无需清理的启动失败场景。
os.Exit 会跳过所有 defer，这不是 bug 是设计
直接调用 os.Exit 后，defer f.Close()、defer db.Close()、defer metrics.Flush() 全都不执行——这是 Go 运行时的明确行为，不是环境异常或版本差异。它绕过函数返回路径，连 defer 栈都不清，进程被操作系统立即终止。
常见错误现象：
-
lsof -p $PID查到大量REG或DEL状态文件句柄 - 数据库连接池持续增长，最终报
dial tcp: i/o timeout - 日志没刷盘、监控指标卡在旧值、临时文件残留
log.Fatal 系列函数和 os.Exit 是一回事
log.Fatal、log.Fatalln、log.Fatalf 都是先打印日志再调用 os.Exit(1)，所以它们和 os.Exit(1) 行为完全一致：defer 不执行、资源不释放、清理逻辑全丢。
容易踩的坑：
立即学习“go语言免费学习笔记（深入）”；
- 在 HTTP handler 里写
log.Fatal("user not found")—— 整个服务进程直接退出，正在处理的请求全中断 - 误以为“打了日志就安全了”，结果
defer resp.Body.Close()永远没机会运行 - 测试中用
log.Fatal模拟错误，导致 cleanup 逻辑无法验证
把业务逻辑塞进 run() 函数，让 return 触发 defer
核心解法就是把 main 里的实际工作抽成一个返回 error 的 run() 函数，所有 defer 放在里面，main 只负责调用和退出码映射。
实操要点：
- 所有资源获取（
os.Open、sql.Open、http.Client初始化）必须在run()内部 -
defer必须紧跟资源获取之后，且前面要有if err != nil { return err }判断，避免对nil调用 -
main函数末尾只做两件事：err := run()和if err != nil { os.Exit(1) }
示例片段：
func run() error {
f, err := os.Open("config.yaml")
if err != nil {
return err // ✅ 此处 return 会触发后续 defer
}
defer f.Close() // ✅ 在 run 返回前必执行
// 其他逻辑...
return nil
}
func main() {
if err := run(); err != nil {
log.Printf("exit with error: %v", err)
os.Exit(1)
}
}
os.Exit 只该用在真·不可恢复的启动失败场景
真正适合 os.Exit 的地方极少：配置加载失败、端口被占、flag 解析出错、证书文件缺失——这些发生在程序主逻辑开始前，没有资源需要清理，也没有 goroutine 在跑。
复杂点在于：很多开发者把“错误严重”等同于“该立刻 os.Exit”，但只要程序已进入业务循环（比如 HTTP server 已启动、goroutine 已 launch），就该走 return err + defer 路径，而不是强杀进程。
容易被忽略的地方：
- goroutine 没等完就
os.Exit，导致后台任务丢数据、日志截断 - 没意识到
runtime.SetFinalizer也依赖正常退出路径，os.Exit下它同样失效 - 测试时用
os.Exit导致 cleanup 逻辑无法覆盖，CI 中资源泄漏难复现
