优雅停机需串联信号监听、HTTP关闭、goroutine清理、依赖退出四环节，缺一不可；否则易卡住或被K8s强杀。
Go 后台服务要真正“优雅停机”，核心不是加个 srv.Shutdown 就完事，而是必须把信号监听、HTTP 服务器关闭、后台 goroutine 清理、依赖组件退出这四件事串成一条可控制、可超时、不互相阻塞的链路。否则进程卡在 Terminating、日志里反复刷 context.DeadlineExceeded、Kubernetes 强杀收场，都是大概率事件。
为什么直接调用 http.Server.Shutdown 会卡住
它本身不监听信号、不设超时、不协调其他组件——只做一件事：等所有活跃 HTTP handler 返回或超时。但如果你没提前通知 goroutine 退出，它们还在死循环里 sleep 或等 channel，Shutdown 就永远等不到“空闲”状态。
-
srv.Shutdown(context.Background())等于没设限，一个没响应的长连接就能让进程 hang 住 - 传
context.WithTimeout(ctx, 5*time.Second)是底线，超时值得比业务最长请求耗时高 1.5 倍（比如最慢接口 8 秒，这里至少设 12 秒） -
Shutdown是阻塞调用，必须放在 goroutine 里跑，否则主 goroutine 卡死，根本收不到 SIGTERM - 别在
defer里关 DB 或 MQ：main 函数退出后 defer 不执行，资源就漏关
如何用 os.Signal 和 sync.WaitGroup 绑定整个生命周期
信号不是用来“触发 shutdown”的开关，而是启动一整套退出流程的起点。关键在于：让所有长期运行的 goroutine 都能感知同一个退出信号源，并主动退出。
- 用带缓冲的通道：
sigChan := make(chan os.Signal, 1)，防丢第一个 SIGTERM - 只监听
syscall.SIGTERM（K8s 默认发）和syscall.SIGINT（本地 Ctrl+C），别加SIGHUP这类无关信号 - 每个后台任务（如 metrics 上报、定时同步）都接收同一个
ctx，并在select中监听ctx.Done()，不能用time.Sleep硬等 - 用
sync.WaitGroup跟踪活跃 handler：在 handler 入口wg.Add(1)，结尾wg.Done()；panic 场景要用defer wg.Done()避免漏减
怎么关掉非 HTTP 的依赖组件
http.Server.Shutdown 只管 HTTP 层。gRPC、DB、Redis、WebSocket、自定义 worker pool 这些，全得手动关，且顺序不能错——先停消费，再等处理，最后释放连接。
立即学习“go语言免费学习笔记（深入）”；
- gRPC Server：必须用
grpcServer.GracefulStop()，不是Stop() -
*sql.DB：调db.Close()（它会等活跃连接归还），不是db.Ping()或什么都不做 - Redis client（如
redis.Client）：调client.Close()，否则底层 TCP 连接残留 - WebSocket 连接：需维护连接池（如
sync.Map），收到 shutdown 信号后遍历调conn.Close() - 第三方中间件（如
promhttp）可能绕过标准生命周期，得查文档确认是否支持 context 取消
Kubernetes 环境下最容易被忽略的兼容点
本地跑通 ≠ 上 K8s 就安全。两个硬性对齐点常被跳过，一出问题就是 502/503 扎堆：
-
terminationGracePeriodSeconds（默认 30 秒）必须比你代码里context.WithTimeout的值大 5–10 秒。比如设了 25 秒超时，K8s 宽限期就得 ≥ 30 秒，否则还没等db.Close()返回，就被 SIGKILL 强杀 - 容器
command必须是["./myapp"]，不能是["sh", "-c", "./myapp"]——后者让 shell 成为 PID 1，不转发 SIGTERM 给子进程 - Go 1.21+ 对连接追踪更细，但自定义
http.Transport或用了某些代理库时，仍可能出现连接未被Shutdown捕获的情况，得靠http.Server.CloseIdleConnections()补一刀
真正的难点不在写几行 shutdown 代码，而在于所有 goroutine 是否都接入了统一的 ctx 控制流。一个没加 select { case 的后台 ticker，就足以让整个服务无法退出。
