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() 返回。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
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 :=
<h3>goroutine 泄漏和 context 超时怎么配合优雅退出</h3>
<p>仅停止接收新请求不够，已启动的 goroutine（比如正在处理的 HTTP 请求、后台定时任务）必须主动退出，否则进程卡住不终止。</p>
<p>核心是用 <code>context.WithCancel</code> 或 <code>context.WithTimeout</code> 统一控制子 goroutine 生命周期，而不是靠全局变量或 sleep 等待。</p>
- 主 goroutine 收到
SIGTERM后调用cancel()，所有子 goroutine 应监听该ctx.Done() - HTTP server 的
Shutdown()方法必须传入带超时的context，否则可能永远等不到连接关闭 - 数据库连接池、消息队列消费者等第三方组件，需查文档确认是否支持 context 取消，不支持的要手动加锁/标记+轮询
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
