Go程序需用signal.Notify注册SIGTERM并阻塞主goroutine，收到信号后在新goroutine中执行清理；defer和os.Exit无法替代，因信号不触发正常退出路径；多信号监听需用带缓冲channel并switch区分处理；优雅退出须结合context控制子goroutine生命周期。
Go 程序怎么监听 SIGTERM 并触发清理逻辑
Go 本身不自动响应系统信号，必须显式用 signal.Notify 注册监听，否则 SIGTERM 会直接终止进程，清理代码根本没机会执行。
典型错误是只写 signal.Notify(ch, syscall.SIGTERM) 却没做阻塞等待或并发协调，导致主 goroutine 退出后整个程序立即结束，清理函数被跳过。
- 必须用
os.Signal类型的 channel 接收信号，不能用chan int或其他类型 - 监听后要确保主 goroutine 不退出（比如用
select{}阻塞，或配合sync.WaitGroup） - 清理函数应在收到信号后尽快执行，但不能阻塞信号接收——推荐把清理逻辑放到单独 goroutine 中，主流程只负责通知
为什么 defer + os.Exit(0) 无法替代信号处理
defer 只在函数返回时触发，os.Exit(0) 会立刻终止进程，跳过所有 defer。SIGTERM 默认行为就是终止进程，不走 Go 的正常退出路径。
常见误操作：在 main() 开头写 defer cleanup()，然后等 SIGTERM 来触发它——这完全无效，因为信号不会让 main() 返回。
立即学习“go语言免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
os.Exit()和 panic 都会绕过 defer，信号默认行为同理 - 真正可靠的清理入口只有一个：你主动读到
SIGTERM后手动调用清理函数 - 如果用了
log.Fatal或第三方库内部调用os.Exit，同样会跳过你的清理逻辑
多个信号怎么同时监听并区分处理
signal.Notify 支持一次注册多个信号，但 channel 是无缓冲的，若未及时读取，新信号会丢失（尤其 SIGINT 连续触发时）。
实际部署中常需同时响应 SIGTERM（K8s 删除 Pod）、SIGINT（Ctrl+C）、SIGHUP（配置重载），但它们语义不同，不能混为一谈。
- 用同一个
chan os.Signal接收多个信号，靠switch sig.(type)分支判断 - 避免在 signal handler 里做耗时操作（如 HTTP 请求、数据库写入），应发通知给主逻辑异步处理
- 若需支持重复信号（比如二次
SIGTERM强制退出），得自己维护状态，Go 标准库不提供“信号计数”能力
sigCh := make(chan os.Signal, 1)
signal.Notify(sigCh, syscall.SIGTERM, syscall.SIGINT)
for {
select {
case sig := <-sigCh:
switch sig {
case syscall.SIGTERM:
log.Println("received SIGTERM, starting graceful shutdown")
shutdown()
case syscall.SIGINT:
log.Println("received SIGINT, exiting now")
os.Exit(0)
}
}
}
goroutine 泄漏和 context 超时怎么配合优雅退出
仅停止接收新请求不够，已启动的 goroutine（比如正在处理的 HTTP 请求、后台定时任务）必须主动退出，否则进程卡住不终止。
核心是用 context.WithCancel 或 context.WithTimeout 统一控制子 goroutine 生命周期，而不是靠全局变量或 sleep 等待。
- 主 goroutine 收到
SIGTERM后调用cancel()，所有子 goroutine 应监听该ctx.Done() - HTTP server 的
Shutdown()方法必须传入带超时的context，否则可能永远等不到连接关闭 - 数据库连接池、消息队列消费者等第三方组件，需查文档确认是否支持 context 取消，不支持的要手动加锁/标记+轮询
