Go程序应避免随意使用os.Exit()，需优雅退出：主动释放资源、等待goroutine完成、统一错误传达；log.Fatal()适用于启动失败场景，不触发defer；main()中应显式用sync.WaitGroup等待goroutine结束。
Go 程序不该用 os.Exit() 随意终止，尤其在有 goroutine、文件句柄或网络连接时；真正“优雅退出”的核心是主动释放资源 + 等待任务完成 + 统一错误传达。
什么时候该用 log.Fatal() 而不是 os.Exit()
log.Fatal() 本质是先调用 log.Println() 打印错误，再调用 os.Exit(1)。它适合「启动失败」类场景，比如配置加载失败、端口被占、数据库连不上——此时程序根本没进入主逻辑，无需清理。
- ✅ 推荐：服务启动阶段的致命错误，如
flag.Parse()后发现必填参数缺失 - ❌ 避免：HTTP handler 中调用
log.Fatal("user not found")—— 这会直接杀掉整个进程，中断所有正在处理的请求 - ⚠️ 注意：
log.Fatal()不会触发defer，也不会执行runtime.SetFinalizer相关逻辑
如何让 main() 等待 goroutine 完成再退出
直接 return 或 os.Exit() 会导致正在运行的 goroutine 被强制终止，可能丢数据、漏日志、连接不关闭。必须显式等待。
- 用
sync.WaitGroup记录活跃 worker 数量，每个 goroutine 结束前调用wg.Done() - 在
main()返回前调用wg.Wait()，但注意：不要在defer wg.Wait()里做，因为defer在函数 return 后才执行，而 main 函数 return 就等于进程退出 - 更稳妥的方式是把等待逻辑放在
main()末尾，例如：func main() { var wg sync.WaitGroup wg.Add(1) go func() { defer wg.Done() http.ListenAndServe(":8080", nil) }() // ... 其他初始化 syscall.SignalNotify(sigChan, os.Interrupt, syscall.SIGTERM) <-sigChan fmt.Println("shutting down...") wg.Wait() // 这里等 server goroutine 自然退出 }
如何捕获 Ctrl+C 和 systemd 的 SIGTERM 实现可中断退出
Linux 服务管理器（systemd、docker stop）和用户终端都靠信号通知进程退出，Go 默认不响应 SIGINT / SIGTERM，需手动监听。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用
signal.Notify()注册信号通道，常见组合：os.Interrupt（Ctrl+C）、syscall.SIGTERM（kill 默认信号） - 不要在 signal handler 里直接调用
os.Exit()—— 这绕过了 cleanup 逻辑；应设一个shutdown标志位或 close 一个done chan，让主逻辑感知并自行退出 - HTTP server 提供了
Shutdown()方法，配合 context 可实现带超时的优雅关闭：srv := &http.Server{Addr: ":8080", Handler: mux} go func() { log.Fatal(srv.ListenAndServe()) }() <-sigChan ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() srv.Shutdown(ctx) // 会等待活跃请求结束，最多等 5s
为什么 panic() 不适合做错误退出路径
panic() 是为“不可恢复的编程错误”设计的，比如数组越界、nil 指针解引用。它会打印堆栈并终止 goroutine，但无法控制退出码，也不便于上层统一处理。
- ❌ 不要用
panic("config file not found")替代错误返回 —— 这会让调用方无法区分是 bug 还是业务异常 - ✅ 如果真要 recover，必须在
main()顶层用defer/recover，且只用于兜底，不能作为常规错误处理手段 - ⚠️
recover()只对当前 goroutine 有效；其他 goroutine 的 panic 仍会导致进程崩溃（除非每个都加 recover）
真正难的不是“怎么退出”，而是定义清楚哪些资源必须释放、哪些任务允许中断、哪些必须做完——这些决策藏在业务逻辑里，没有通用模板。信号监听、WaitGroup、context.Cancel、server.Shutdown 这些只是工具，用不用、怎么串，全看你的 cleanup 清单是否完整。
