http.server.shutdown是唯一靠谱的选择，因其能先拒新连、再等旧连自然完成或超时，避免os.exit()硬中断请求或server.close()强制断连；必须配带超时的context且handler需响应ctx.done()。
为什么 http.Server.Shutdown 是唯一靠谱的选择？
直接调用 os.Exit() 或杀进程会导致正在处理的 HTTP 请求被强制中断，客户端收到 EOF 或 connection reset；而只关闭监听器（server.Close()）又无法等待活跃连接完成。Go 标准库从 1.8 起提供的 http.Server.Shutdown() 才是真正支持优雅停机的接口——它会拒绝新连接、等待已有请求完成（含长连接和流式响应），并在超时后强制终止。
常见错误是没配超时或没处理上下文取消信号：
- 不设
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)，Shutdown()可能永远阻塞 - 没在 handler 中检查
ctx.Done()，比如time.Sleep(60 * time.Second)这类阻塞操作不会自动响应 shutdown - 忘记对
http.Server显式调用Shutdown()，而是依赖 deferserver.Close()—— 这等同于粗暴中断
如何让 gRPC Server 也一起平滑退出？
gRPC Go 的 *grpc.Server 没有内置 Shutdown() 方法，必须手动触发 graceful stop：先停止接收新请求（GracefulStop()），再等待已接受的 RPC 完成。关键点在于它和 HTTP server 必须协同超时，且不能互相阻塞。
实操建议：
- 用同一个
context.Context控制两个 server 的 shutdown 超时，避免一个早退、一个卡住 -
GracefulStop()会阻塞直到所有 RPC 结束，所以必须确保每个 handler 都尊重ctx.Done()，例如用select { case - 若服务同时暴露 HTTP 和 gRPC，建议用
sync.WaitGroup等待两者都完成 shutdown，再退出进程
示例片段：
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
var wg sync.WaitGroup
wg.Add(2)
go func() {
defer wg.Done()
httpServer.Shutdown(ctx)
}()
go func() {
defer wg.Done()
grpcServer.GracefulStop()
}()
wg.Wait()
Signal handling 怎么写才不丢请求？
监听 SIGTERM（Kubernetes 默认发送）和 SIGINT（Ctrl+C）是标准做法，但容易踩坑：信号 handler 启动 shutdown 流程后，如果立即 return，main goroutine 退出会导致整个进程终止，而 shutdown 还在跑。
正确做法是阻塞住 main goroutine，直到 shutdown 完成：
- 用
signal.Notify(c, os.Interrupt, syscall.SIGTERM)接收信号 - 收到信号后启动 shutdown，但不要 return；改用
等待 shutdown 完成（<code>done是 shutdown 完毕后 close 的 channel） - 避免在 signal handler 里做耗时操作（如写日志到网络），否则可能错过后续信号或延迟 shutdown 启动
第三方组件（DB、Redis、MQ）怎么同步停机？
HTTP/gRPC server 停了，但数据库连接池还在往 DB 发心跳、Redis client 还在重连、消息消费者还在拉取新消息——这些都会导致资源浪费甚至数据不一致。真正的平滑停机必须包含它们。
每种组件处理方式不同：
-
database/sql：调用db.Close()，它会等待所有活跃连接归还并关闭连接池；但需确保之前所有db.Query/Exec都带 context 并及时响应 cancel -
redis.Client（github.com/go-redis/redis/v8）：调用client.Close()，它会主动断开连接并停止重试；注意别在 Close 后继续调用client.Get()，会 panic - 消息队列（如 kafka、nats）：先停止消费（
consumer.Stop()或取消 consumer ctx），再等待 inflight 消息处理完，最后关闭连接
最容易被忽略的是：这些 cleanup 必须在 http.Server.Shutdown() 开始前触发，而不是等它结束——因为 DB/Redis 的关闭本身也需要时间，且不应拖慢 HTTP 连接的 graceful wait。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
