os.Exit() 之所以会让所有 defer 失效，关键就在于它会直接终止进程，函数正常返回这条路径根本不会走完，自然也就谈不上执行 defer。真想把退出做得稳妥、干净，就得同时监听 os.Interrupt 和 syscall.SIGTERM，signal channel 最好设成带缓冲的，再配合 context.WithTimeout 和 sync.WaitGroup，把 goroutine 和相关资源按顺序清理到位。

为什么 os.Exit() 会让 defer 失效

os.Exit() 的特点就在于“立刻结束进程”，它不会按正常的函数返回流程往下走。结果就是，所有已经注册的 defer 都不会有执行机会——不管是在 main 函数里，还是在其他 goroutine 里，统统都会被直接跳过。随之而来的问题也很现实：临时文件可能来不及清理，数据库连接可能没被正常关闭，日志也可能还没来得及 flush。这并不是 bug，而是 Go 明确的设计取舍：它只保证在“正常返回”这条路径上执行 defer，至于收到信号或被强制退出时的清理，并不在承诺范围内。

必须同时监听 os.Interrupt 和 syscall.SIGTERM

只监听 os.Interrupt 能响应 Ctrl+C，但在 Kubernetes、systemd 或 docker stop 场景下，进程收到的是 syscall.SIGTERM。漏掉它，服务就“硬退”了。

• sigChan := make(chan os.Signal, 1) —— 缓冲区大小至少为 1，避免并发信号丢失
• signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM) —— 两个信号注册在同一 channel
• 必须有 <-sigChan 阻塞接收，否则 main 函数跑完就退出，监听形同虚设

HTTP Server Shutdown 必须配超时 context

srv.Shutdown() 本身不等待，它只是发通知；真正控制等待时长的是你传进去的 context.Context。用 context.Background() 等价于“立刻关”，长请求会被中断。

• 正确写法：ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
• 调用后必须 defer cancel()，防止 context 泄漏
• 绝对不要在 Shutdown() 前调 srv.Close()，那会直接断连，破坏“优雅”
• ListenAndServe() 返回 http.ErrServerClosed 是预期行为，需显式忽略，不是错误

goroutine 清理不能靠 defer，得用 done channel 或 context.Done()

goroutine 内部的 defer 在进程被杀时根本不会执行——它的栈没机会“返回”。所有长期运行的 goroutine（定时器、消息轮询、日志 flush）必须主动响应退出信号。

• 推荐统一用 context.Context：启动前 ctx, cancel := context.WithCancel(parentCtx)，传给所有 worker
• worker 内部用 select { case <-ctx.Done(): return }，而不是轮询 ctx.Err()（忙等 + 延迟）
• 配合 sync.WaitGroup：每个 goroutine 启动前 wg.Add(1)，退出前 wg.Done()（必须在 ctx.Done() 分支里做）
• 主流程收到信号后，先 cancel()，再 wg.Wait()，最后才关 DB/Redis 连接——顺序错一步，资源就可能泄漏或 panic

最易被忽略的点：清理逻辑必须和资源创建在同一个作用域内显式配对，比如临时文件用 os.CreateTemp 创建后，立刻把路径记入一个切片，退出时遍历删除；别指望某个全局 defer 能兜底——它根本没机会运行。

《夸克》非常好用的免费AI浏览器

下载APP查看