Go语言信号捕获退出技巧教程

本文深入解析了Go语言中实现优雅退出的关键技术——通过os/signal包捕获SIGINT和SIGTERM信号，直击实践中常遇的“信号捕获失效”痛点，揭示根本原因在于外部环境（如Docker默认不转发信号、systemd未配置KillMode=process）导致信号未送达进程，或程序未正确阻塞等待信号；并给出简洁可靠的解决方案：结合signal.Notify与阻塞式channel等待，确保服务在接收到终止信号后能安全清理资源、完成正在处理的请求，真正实现平滑下线。

Go 中 os.Signal 捕获不到 SIGINT 或 SIGTERM？检查信号是否被父进程屏蔽

默认情况下 Go 程序能收到 SIGINT（Ctrl+C）和 SIGTERM，但如果你在容器、systemd 或 shell 脚本里运行，信号可能根本没传进来。比如 docker run 默认不转发 SIGTERM 给主进程；systemd 服务若没配 KillMode=process，会直接杀整个 cgroup，跳过 Go 的信号处理逻辑。

• 用 strace -e trace=rt_sigprocmask,rt_sigaction,kill 启动程序，确认信号是否抵达进程
• 容器中加 --init 参数（如 docker run --init），避免信号被 init 进程吞掉
• systemd 服务文件里显式写 KillSignal=SIGTERM 和 KillMode=process

signal.Notify 后程序没退出？别忘了阻塞等待信号

signal.Notify 只是注册监听，它不会自动让主 goroutine 等待。常见错误是注册完就直接执行后续逻辑，甚至 main 函数返回，导致程序提前退出，信号根本来不及处理。

• 必须用一个 channel（比如 sigChan := make(chan os.Signal, 1)）配合 signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
• 然后用 <-sigChan 阻塞住主 goroutine，等信号到来
• 不要用 time.Sleep 或空 for {} 替代 —— 前者不可靠，后者占满 CPU

优雅退出时资源清理失败？context.WithCancel + sync.WaitGroup 是标配

仅捕获信号不够，HTTP server 关闭、数据库连接释放、goroutine 退出都需要时间。直接退出会导致连接中断、数据丢失或 panic。

• 启动前创建 ctx, cancel := context.WithCancel(context.Background())，把 ctx 传给所有需要响应退出的组件
• 每个长期运行的 goroutine 开头加 select { case
• 用 sync.WaitGroup 记录活跃 worker，cancel() 后调 wg.Wait() 等它们结束
• HTTP server 关闭要带超时：srv.Shutdown(ctx)，而不是 srv.Close()

为什么 SIGHUP 在某些环境收不到？Go 默认不监听它

Go 的 os/signal 包默认只关注 SIGINT 和 SIGTERM，SIGHUP（比如终端断开、nohup 启动）需显式添加。而且 Linux 下，如果进程不是 session leader，SIGHUP 可能根本不会发给它。

• 要支持 SIGHUP，必须在 signal.Notify 里加上：syscall.SIGHUP
• 守护进程需调用 syscall.Setpgid(0, 0) 或使用 setsid() 成为 session leader，否则收不到 SIGHUP
• 注意：Windows 不支持 SIGHUP，跨平台代码要加 // +build !windows 构建约束

信号处理最易被忽略的点是「信号到达」和「程序响应」之间存在非原子间隙：从收到信号到执行 cleanup，中间任何 panic、死锁或未覆盖的 goroutine 都会让退出卡住。别假设所有资源都支持 context 取消 —— 有些底层库（比如老版本 pgx、某些 Cgo 封装）需要手动关连接、调 Close() 或发自定义停止指令。

好了，本文到此结束，带大家了解了《Go语言信号捕获退出技巧教程》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！