不能直接用 defer 或 main 函数退出清理资源，因为 defer 只在函数返回时执行，而 kubernetes 发送 sigterm 后进程可能仍在运行、请求未处理完，且 db 连接池等长生命周期组件已脱离作用域；若未主动响应信号，30 秒后将被强制 sigkill，导致连接泄漏、消息丢失、事务中断。
为什么不能直接用 defer 或 main 函数退出来清理资源
main 函数返回或 panic 时，defer 确实会执行，但此时 HTTP 服务可能还在处理请求，DB 连接池、MQ 消费者等长生命周期组件早已脱离作用域，defer 根本捕获不到它们的关闭时机。更严重的是，Kubernetes 发送 SIGTERM 后，进程若未主动响应，会在 30 秒后被强制 KILL，导致连接泄漏、消息丢失、事务中断。
常见错误包括：
- 把
db.Close()放在main末尾的defer里——它只在函数结束时调用，而信号到来时main还没退出 - 用
http.ListenAndServe()启动服务——它阻塞主 goroutine，signal.Notify完全收不到信号 - 多个资源 Close() 顺序错乱，比如先关 DB 再停消费者，导致消费者回调里查库失败 panic
如何用统一 Lifecycle 结构体注册和触发回调
核心是封装一个可管理状态的 Lifecycle 结构体，内部维护有序的 onStop 回调切片，并提供 RegisterStop(func(context.Context) error) 方法供各组件注册自己的关闭逻辑。
关键设计点：
- 回调注册必须早于服务启动，否则信号来临时还没注册完
- 所有
RegisterStop调用应按「反向依赖」顺序：HTTP Server 最后关，DB 和 MQ 消费者先关 - 每个回调函数必须接收
context.Context并支持超时，避免某个组件卡死拖垮整个关机流程 - 结构体内置
atomic.Bool记录是否已触发停止，防止重复执行
示例注册顺序：
lifecycle.RegisterStop(func(ctx context.Context) error {
return amqpConn.Close()
})
lifecycle.RegisterStop(func(ctx context.Context) error {
return db.Close()
})
lifecycle.RegisterStop(func(ctx context.Context) error {
return srv.Shutdown(ctx)
})
收到 SIGTERM 后，Shutdown 流程必须分两步走
srv.Shutdown() 不等于“关服务”，它只负责等待已有连接完成，但监听 socket 仍开着，新请求还会进来。标准流程必须是：srv.Close() → srv.Shutdown()。
原因和细节：
-
srv.Close()立即返回，让srv.ListenAndServe()返回http.ErrServerClosed，不再接受新连接 -
srv.Shutdown()是阻塞操作，需传入带超时的context（如context.WithTimeout(ctx, 15*time.Second)），防止长连接拖住整个流程 - 不要在
Shutdown()返回后再调Close()，会 panic - 检查
srv.ListenAndServe()的返回值：仅当不是http.ErrServerClosed时才记录 error 并退出
GORM、Redis、AMQP 等组件怎么接入 Lifecycle
它们本身大多已提供 Close() 方法，但直接调用不够——缺少上下文控制和错误聚合。正确做法是包装一层，统一转为 func(context.Context) error 回调。
典型适配方式：
-
*sql.DB：用db.Close()，但注意它不等连接池清空；更稳妥的是先db.SetMaxOpenConns(0)阻止新连接，再等db.Stats().OpenConnections == 0后调Close() -
*redis.Client：直接client.Close()即可，它内部已做 graceful 处理 -
*amqp.Connection：调conn.Close()，但需确保所有 channel 已关闭，否则会 panic - 自定义 worker pool：暴露
Stop(ctx context.Context)方法，内部用ctx.Done()通知 goroutine 退出，再用sync.WaitGroup等待全部结束
最容易被忽略的是：所有 Close 逻辑必须在同一个 signal handler 里串行执行，不能并发调用——否则 DB 关闭过程中，MQ 消费者还在往 DB 写数据，就会出错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
