Golang优雅关机信号捕获方法

大家好，我们又见面了啊~本文《Golang捕获系统信号实现优雅关机》的内容中将会涉及到等等。如果你正在学习Golang相关知识，欢迎关注我，以后会给大家带来更多Golang相关文章，希望我们能一起进步！下面就开始本文的正式内容~

生产环境必须同时监听 SIGTERM 和 SIGINT 以支持优雅关闭，仅监听 SIGINT 会导致容器或 systemd 下强制终止；Shutdown 前需先关闭 listener，context 超时应比平台终止宽限期短 5s，并排查 goroutine 泄漏。

为什么 signal.Notify 不能只监听 SIGINT 就收工

生产环境里，SIGINT（Ctrl+C）只是个开发调试信号；真正上线后，进程大概率被 SIGTERM 终止（比如 systemd、K8s 的 kill -15）。只监听 SIGINT 会导致服务在容器或 systemd 下无法优雅退出，直接被强制杀掉。

实操建议：

• 必须同时监听 SIGTERM 和 SIGINT，两者行为一致，都走优雅关闭流程
• 避免监听 SIGHUP 或 SIGUSR1 等非标准终止信号，除非你明确要支持热重载等扩展行为
• 不要用 signal.Ignore 屏蔽其他信号——它可能干扰 runtime 内部信号处理（如 SIGQUIT 用于 panic trace）

http.Server.Shutdown 调用前必须先关掉 listener

http.Server.Shutdown 是阻塞的，但它不会自动停掉底层 listener。如果 listener 还开着，新连接仍可能被 accept 进来，而此时 handler 已开始拒绝请求，导致连接半开、超时或 503 混乱。

实操建议：

• 调用 srv.Shutdown 前，先执行 ln.Close()（其中 ln 是你传给 srv.Serve 的 net.Listener）
• 推荐用 net.Listen 显式创建 listener，而不是直接传地址给 http.ListenAndServe，否则拿不到 ln 实例
• 注意：srv.Close() 是粗暴关闭（立即断连），不是优雅关闭，别误用

Context 超时时间必须短于系统级 kill timeout

很多部署环境（如 Kubernetes、systemd）会在发 SIGTERM 后等待固定时间（如 30s），超时就发 SIGKILL 强制终止。如果你设的 context.WithTimeout 是 60s，服务大概率被硬杀，根本来不及完成 Shutdown。

实操建议：

• 设置 shutdown context 超时值 = 部署平台的 terminationGracePeriodSeconds − 5s（留出缓冲）
• 例如 K8s 设了 terminationGracePeriodSeconds: 30，代码里就用 context.WithTimeout(ctx, 25*time.Second)
• 不要依赖 http.Server.IdleTimeout 替代 shutdown 超时——它只管空闲连接，不管正在处理的请求

goroutine 泄漏常藏在中间件或后台任务里

优雅关闭失败，十次有八次不是 Shutdown 本身的问题，而是某个 goroutine 卡在 I/O、channel receive 或无休止 for-select 循环里，导致 Shutdown 一直阻塞不返回。

实操建议：

• 检查所有注册的中间件：是否启动了长生命周期 goroutine（如轮询、定时器）？它们是否接收并响应 shutdown 信号？
• 数据库连接池、消息队列消费者等外部依赖，必须显式调用其 Close 方法，并确保它们也带 context 控制
• 用 runtime.NumGoroutine() 在 shutdown 前后打日志，快速定位泄漏点

最麻烦的从来不是怎么写 shutdown 逻辑，而是得把所有“悄悄跑起来”的 goroutine 全揪出来，挨个加退出机制。没人替你记着那些匿名 go func 里有没有 select

到这里，我们也就讲完了《Golang优雅关机信号捕获方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！