os.exit 会跳过 defer 执行，导致资源泄漏；应将业务逻辑封装为返回 error 的 run 函数，在其中使用 defer 管理资源，main 仅调用 run 并根据错误调用 os.exit。
直接用 os.Exit 退出，defer 不会执行——这是 Go 里最常被忽略的资源泄漏源头之一。
为什么 os.Exit 会跳过 defer
os.Exit 的设计就是“立刻终止进程”，不走任何函数返回路径。而 defer 只在函数正常 return、panic 恢复或函数执行完毕时触发，它依赖的是函数退出的控制流。一旦调用 os.Exit，整个进程被操作系统强制结束，Go 运行时连清理栈的机会都没有。
常见错误现象：
- 文件句柄未关闭，
lsof查到大量REG或DEL状态的 fd - 数据库连接池耗尽，后续请求卡在
dial tcp: i/o timeout - 日志没刷盘、监控指标没上报、临时文件没清理
main 函数里别直接调用 os.Exit
把业务逻辑抽成一个返回 error 的 run 函数，让 defer 在其作用域内自然生效。
实操建议：
- 所有资源打开（
os.Open、sql.Open、http.Client初始化等）都放在run()内部 -
defer语句必须紧跟资源获取之后，且确保资源非 nil（比如if err != nil { return err }必须在defer f.Close()前） -
main只做两件事：调用run()，根据返回值决定是否os.Exit(1)
示例：
func run() error {
f, err := os.Open("config.yaml")
if err != nil {
return err // ✅ defer 不会执行，但这里没 defer，安全
}
defer f.Close() // ✅ 在 run 返回前必执行
// 其他逻辑...
return nil
}
func main() {
if err := run(); err != nil {
log.Printf("fatal: %v", err)
os.Exit(1) // ✅ 此时 run 已返回，所有 defer 已跑完
}
}
defer 参数求值时机容易误判
defer 后面的表达式参数，在 defer 语句执行（即注册）时就求值完毕，不是等到实际调用时才取值。这对日志时间、错误包装、循环变量尤其关键。
容易踩的坑：
- 写
defer log.Println(time.Now())，记录的是注册时刻，不是退出时刻 - 在 for 循环里写
defer func() { fmt.Println(i) }()，最后全输出同一个值（闭包捕获变量） - 想包装错误却用了匿名返回值：
func() error { e := errors.New("x"); defer func() { e = fmt.Errorf("wrap: %w", e) }(); return e }→ 实际返回原始e
正确做法：
- 要记录退出时间，写成
defer func() { log.Println(time.Now()) }() - 循环中需要绑定当前值，显式传参：
defer func(v int) { fmt.Println(v) }(i) - 需修改返回值，用命名返回值：
func f() (err error) { ... defer func() { err = fmt.Errorf("wrap: %w", err) }() }
替代方案：用 log.Fatal？同样绕过 defer
log.Fatal、log.Fatalln、log.Fatalf 内部都调用了 os.Exit(1)，所以它们和 os.Exit 一样，会跳过所有 defer。不要以为加了日志就更“安全”。
如果你已经习惯用 log.Fatal 快速退出，现在就得改掉——要么换成 return + 错误传播，要么手动补清理（比如先 f.Close() 再 log.Fatal），但后者不可扩展、易遗漏。
真正复杂的地方在于：当多个 goroutine 同时启动，主 goroutine 调用 os.Exit，其他 goroutine 的 defer 也不会执行；而你根本没法在 main 里等它们全部退出——这正是为什么封装 run + 显式错误传播是唯一可维护的路径。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
