os.Exit会跳过所有defer，这是Go运行时的明确设计而非bug；它绕过函数返回路径，导致已注册的defer全不执行，仅适用于配置加载失败等无需清理的极端场景。
os.Exit 会跳过所有 defer，这是确定行为，不是 bug
直接调用 os.Exit 会导致程序立即终止，**已注册的 defer 函数一个都不会执行**。这不是异常或环境问题，而是 Go 运行时的明确设计：它绕过函数返回路径，不触发任何 defer 栈清空逻辑。
- 常见错误现象：
defer f.Close()在os.Exit(1)前注册，但文件句柄始终未释放，造成资源泄露 - 使用场景：仅适合进程启动失败（如配置加载失败、端口被占）等“不可恢复且无需清理”的极端情况
- 性能 / 兼容性影响：无额外开销，但会破坏依赖 defer 的资源管理契约，下游测试、监控、日志等 cleanup 逻辑全部失效
log.Fatal 系列函数本质就是 os.Exit(1)，同样跳过 defer
log.Fatal、log.Fatalln、log.Fatalf 都在打印日志后调用 os.Exit(1)，因此行为完全一致——defer 不执行。
- 容易踩的坑：误以为 “打了日志就安全了”，结果数据库连接没关、临时文件没删、metrics 没 flush
- 替代方案：用
log.Printf+ 显式return或封装run()函数（见下一条） - 参数差异：无；
log.Fatalf("err: %v", err)和log.Printf("err: %v", err); os.Exit(1)效果相同，都跳 defer
用 run() 函数封装主逻辑，让 return 触发 defer
把实际业务逻辑放进一个返回 error 的 run() 函数里，main 中只做错误判断和退出码映射。这样所有 return 都走标准返回路径，defer 自然生效。
- 示例结构：
func main() {
if err := run(); err != nil {
log.Printf("fatal error: %v", err)
os.Exit(1) // ← 此处 os.Exit 已在 defer 全部执行完之后
}
}
func run() error {
f, err := os.Open("config.yaml")
if err != nil {
return err // ← defer 不会在这里跳过
}
defer f.Close() // ← 一定会执行
db, err := sql.Open(...)
if err != nil {
return err
}
defer db.Close()
// ... 其他逻辑
return nil
}
- 为什么这样做：
run()的return触发 defer 执行，main()中的os.Exit只是最后一步，不再干扰资源清理 - 容易踩的坑：把
os.Exit写在run()里，或在run()中混用log.Fatal - 注意：如果
run()中发生 panic，defer 仍会执行（除非被os.Exit中断），所以 recover 应放在run()内部而非 main
defer 参数求值时机早于变量变更，闭包捕获的是地址不是值
这不是 os.Exit 的问题，但常在错误处理路径中连带暴露——比如循环里 defer 删除临时文件，结果全删最后一个。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
for i := range files { defer os.Remove(files[i]) }→ 全部删files[len(files)-1] - 正确做法一（重绑定）：
for i := range files { i := i; defer os.Remove(files[i]) } - 正确做法二（传参）：
for _, f := range files { defer func(name string) { os.Remove(name) }(f) } - 关键点：defer 注册时，普通变量按值拷贝，指针/切片/结构体字段按地址捕获；别指望 defer 里看到“最终值”
os.Exit 跳 defer，而是当业务越来越复杂、panic 路径增多、goroutine 异步退出混入时，依然能保证每个资源都有且仅有一次 clean up。这时候靠人工检查 defer 位置远远不够，得靠结构约束（比如强制 run 函数）、静态分析（如 go vet 检查未使用的 defer）、以及测试覆盖所有错误分支。 
