http.server.shutdown不能直接用context.background()，因无超时会导致永久阻塞；应使用context.withtimeout设置30秒超时，并检查返回错误；同时需协调db、kafka等依赖资源的有序关闭，配合sync.once和channel确保shutdown逻辑只执行一次。
为什么 http.Server.Shutdown 不能直接用 context.Background()
因为 http.Server.Shutdown 会阻塞等待所有活跃连接完成，但若没设超时，它可能永远等下去——尤其当客户端不主动断开（比如长轮询、WebSocket 或 HTTP/2 流），服务就卡在关机阶段。生产环境必须控制停机时间窗口，通常要求 30 秒内彻底退出。
正确做法是传入带超时的 context.Context，并在超时后强制关闭监听器和未完成请求：
- 用
context.WithTimeout(context.Background(), 30*time.Second)构造上下文 - 调用
srv.Shutdown(ctx)后，检查返回错误：如果是context.DeadlineExceeded，说明有请求没结束，此时应记录日志并继续执行清理逻辑 - 不要忽略
srv.Shutdown的返回值——它可能返回http.ErrServerClosed（正常）或非 nil 错误（异常）
如何安全终止依赖资源（DB 连接池、消息队列消费者）
HTTP 服务器停机只是第一步。如果数据库连接池还在接受新查询、Kafka 消费者还在拉取消息，进程就不能真正退出。关键原则是：先停止接收新工作，再等已有任务完成，最后释放资源。
以 sql.DB 为例，db.Close() 并不会立即断开连接，而是阻止新查询，并等待所有正在执行的查询结束；但它不设超时，所以需配合手动控制：
- 在
Shutdown开始前调用db.SetMaxOpenConns(0)，阻止新连接获取 - 等待几秒（如 5 秒），再调用
db.Close()；若仍卡住，可记录警告但不阻塞主流程 - 对于 Kafka 消费者，调用
consumer.Close()后应监听其返回的error，并确认RebalanceListener.OnRevoked已触发（确保分区已交还）
信号监听与并发安全的 shutdown 流程怎么组织
Go 程序常通过 os.Interrupt 或 syscall.SIGTERM 触发停机，但多个 goroutine 同时响应信号会导致重复执行 shutdown 逻辑，甚至 panic。
推荐用单次执行 + channel 同步的方式：
- 定义全局
shutdownOnce sync.Once和shutdownCh chan struct{} - 在信号监听 goroutine 中，首次收到信号时调用
shutdownOnce.Do(func(){ close(shutdownCh) }) - 主逻辑里用
select { case 响应，避免竞态 - 不要在
defer里调用 shutdown 函数——它可能被多次执行，且无法控制执行时机
http.Server.RegisterOnShutdown 的实际用途很有限
这个方法注册的函数只在 srv.Close() 或 srv.Shutdown() 返回后执行，且不接收 context、无法取消、也不能报告错误。它适合做纯内存清理（比如清空本地缓存 map），但不适合涉及 I/O 或超时控制的操作。
真正需要可靠执行的清理动作，应该放在 Shutdown 调用之后、进程退出之前的手动序列里：
- 例如：先
srv.Shutdown(ctx)，再db.Close()，再redisPool.Close()，每一步都单独判断错误并记录 -
RegisterOnShutdown里只放“尽力而为”的操作，比如log.Println("server shutdown complete") - 它不参与 shutdown 超时控制——即使里面 sleep 10 秒，也不会被外部 context 取消
真正的优雅，不是让每个组件都“完美收尾”，而是明确各环节的超时边界、失败容忍和日志可观测性。生产环境里，一个没及时关闭的 goroutine 比一条没 commit 的事务更危险——因为它会让进程悬而不死。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
