os.Exit() 不执行任何 defer 语句，因其直接终止进程，跳过 Go 运行时退出流程；log.Fatal() 同理，defer 在其前绝不执行，资源清理须手动调用或改用 return。
os.Exit() 不会执行任何 defer 语句——这是 Go 中明确且不可绕过的规则。
为什么 defer 在 os.Exit() 前完全失效
Go 的 os.Exit() 是直接向操作系统发起进程终止调用，跳过 Go 运行时的常规退出流程。这意味着：
-
defer注册的函数不会被弹出执行（哪怕它早已入栈） - 所有未 flush 的日志、未关闭的文件句柄、未释放的锁、未提交的事务，都会被强制丢弃
- 即使
defer写在os.Exit()之前，也**绝对不保证执行**
func main() {
defer fmt.Println("这个不会打印")
fmt.Println("main running...")
os.Exit(1)
}
运行后只会输出 main running...，然后立即退出。
哪些场景下你可能误以为 defer 会执行
常见混淆点来自对其他退出方式的混用：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
return：会触发defer（正常函数返回） -
panic()：会触发defer（包括能被recover()捕获的 panic） -
log.Fatal()：底层调用了os.Exit(1)，所以同样**跳过 defer**（不是“先 log 再 defer”，而是 log 后直退）
注意：log.Fatal() 和 os.Exit() 行为一致，只是多了一次日志输出；它不是“带 defer 的 exit”。
如何安全退出并确保资源清理
若你依赖 defer 做资源清理（如 f.Close()、mu.Unlock()），就不能在同函数内混用 os.Exit()。替代方案有：
- 用
return配合命名返回值或显式错误处理，让defer自然触发 - 把需要清理的逻辑封装进独立函数，在其中统一用
return控制流程 - 若必须提前终止且需清理，手动调用清理函数，再
os.Exit()
func main() {
f, _ := os.Open("data.txt")
defer f.Close() // ✅ 安全：靠 return 触发
if badCondition {
// ❌ 错误：os.Exit(1) 会让 defer f.Close() 失效
// os.Exit(1)
// ✅ 正确：显式关掉，再退出
f.Close()
os.Exit(1)
}
}
最易被忽略的一点：defer 的参数是定义时拷贝的值，而 os.Exit() 让你连这个“拷贝时机”都来不及利用——它彻底切断了 defer 栈的执行机会。写工具类命令行程序时，这点尤其关键：别让一个 os.Exit(2) 悄悄泄漏了数据库连接或临时文件。
