唯一靠谱的优雅停机方案是http.Server.Shutdown()配合带超时的context.Context，并手动协调下游资源：先关监听器、再等待请求完成，最后按反向依赖顺序关闭DB、gRPC、WebSocket等。
直接调用 http.Server.Close() 或忽略信号硬退出，会导致上传中断、流响应截断、事务未提交、客户端收到 connection reset by peer——这不是“快”，是“糙”。真正可用的路径只有一条：http.Server.Shutdown() 配合带超时的 context.Context，且必须手动协调下游资源。
为什么 Shutdown() 是唯一靠谱的选择
http.Server.Shutdown() 会先关闭监听器（拒绝新连接），再逐个等待已有请求完成（含长轮询、SSE、gRPC 流），超时后才强制退出。它不中断正在写的 response body，也不跳过 defer 里的数据库事务提交。
- 传
context.Background()或没设 deadline 的context.WithCancel()→ 可能永远阻塞（比如某个客户端不发 FIN） - 错误写法：
srv.Shutdown(context.Background())；正确写法：ctx, cancel := context.WithTimeout(context.Background(), 25*time.Second)，之后srv.Shutdown(ctx)，最后立刻cancel() -
Shutdown()返回context.DeadlineExceeded是正常现象，说明有请求卡住，记录日志即可，不必 panic，更不能 fallback 到Close()
信号监听必须带缓冲 + 显式接收
只写 signal.Notify(sigChan, syscall.SIGTERM, os.Interrupt) 不够——这只是注册，不触发任何行为。主 goroutine 若随后直接跑 srv.ListenAndServe()，就会被阻塞，永远收不到信号。
-
sigChan := make(chan os.Signal, 1)：缓冲为 1，防丢第一个信号（比如 K8s 连续发 SIGTERM） - 必须显式阻塞接收：
<-sigChan或for range sigChan，不能把 signal.Notify 放进 goroutine 就不管 - 只监听
os.Interrupt（Ctrl+C）和syscall.SIGTERM（K8s 默认），别加SIGHUP等无关信号 -
srv.ListenAndServe()必须起在 goroutine 里，否则主 goroutine 卡死，信号收不到
HTTP 之外的资源必须手动关，且顺序不能错
http.Server.Shutdown() 只管 HTTP 连接层，*sql.DB、*grpc.Server、WebSocket 连接、后台 goroutine 全得你亲手关。漏一个，进程就卡住；顺序错一个，可能 panic 或数据丢失。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 关闭顺序必须反向依赖：先停消息消费者（如 Kafka），再等 DB 连接池空闲（
db.SetMaxOpenConns(1)加速归还），最后关 HTTP server -
*sql.DB.Close()是阻塞操作，要确保此前已无新查询发起；grpcServer.GracefulStop()不等流式 RPC 完成，需业务层配合 ctx 超时 - WebSocket 连接不会被
Shutdown()自动等待，得自己维护sync.Map存活连接，收到 shutdown 信号后遍历调conn.Close() - 后台 goroutine（如 metrics 上报）必须监听统一
ctx.Done()，不能用time.Sleep硬等
K8s 环境下必须对齐 terminationGracePeriodSeconds 和 Shutdown 超时
K8s 删除 Pod 时，给容器的总宽限期由 terminationGracePeriodSeconds 决定（默认 30 秒）。Go 代码里的 Shutdown() 超时必须比它小 5–10 秒，比如设成 20–25 秒。否则 K8s 在超时后直接发送 SIGKILL 强杀，你的清理逻辑根本没机会执行完。
- 同时确认容器
command是["./myapp"]，而非["sh", "-c", "./myapp"]——后者让 shell 成为 PID 1，不转发信号给子进程 - preStop 钩子建议只做轻量操作（如调
/healthz切 503），别在里面等 DB drain；重逻辑交给 Go 主程序自己处理 - readinessProbe 探测接口需与 shutdown 逻辑联动：收到信号后立即返回 503，让 K8s Endpoint Controller 尽快摘除实例
最常被忽略的一点：Shutdown() 不会自动关闭监听套接字，它只协调连接层面的 graceful 结束；而监听器关闭由 ListenAndServe() 返回 http.ErrServerClosed 触发——因此务必确保主 goroutine 能捕获到该错误并进入停机流程，而不是靠 defer 或信号 handler 里裸调 Shutdown() 就以为万事大吉。
