go服务需手动监听sigterm/sigint并触发优雅关机：用signal.notify捕获信号，统一context控制grpc gracefulstop、http shutdown及资源清理，后台goroutine须监听ctx.done()避免泄漏。
Go 服务收到 SIGTERM 后立即退出？那是没接住信号
Go 程序默认对 SIGTERM 和 SIGINT 是直接终止的，不会等 HTTP server 关闭连接、RPC server 拒绝新请求、goroutine 清理资源。结果就是客户端收到 connection reset 或超时，gRPC 调用可能卡在 UNAVAILABLE 状态。
必须手动监听信号，并触发 shutdown 流程。核心是：用 signal.Notify 拦住信号，再调用各组件的 Shutdown 方法。
-
http.Server有Shutdown(context.Context)，需传入带超时的context，否则会永久阻塞 -
grpc.Server没有内置Shutdown，得调GracefulStop()（等待已有请求结束）或Stop()（立即断连），生产环境只用GracefulStop() - 自定义 goroutine（比如心跳上报、消息轮询）要自己接收
context.Done()并退出，不能靠 panic 或 os.Exit
HTTP 和 gRPC Server 怎么同时优雅关机？别各自为政
一个微服务常同时暴露 HTTP（健康检查、指标）和 gRPC（业务接口），但它们 shutdown 时机不同步，容易出现「HTTP 已停、gRPC 还在收请求」或「gRPC 已停、HTTP 健康探针还在返回 200」的问题。
正确做法是统一用一个 context 控制生命周期，所有 shutdown 动作串行执行，且加超时兜底：
立即学习“go语言免费学习笔记（深入）”；
ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second)
defer cancel()
// 先关闭 gRPC（拒绝新请求，等旧请求完成）
grpcServer.GracefulStop()
// 再关 HTTP（同理）
if httpServer != nil {
httpServer.Shutdown(ctx)
}
// 最后清理 DB 连接池、Redis 客户端等
db.Close()
redisClient.Close()
注意：GracefulStop() 本身不超时，必须靠外层 context 控制整体时限；http.Server.Shutdown() 会在 ctx 超时后强行关闭未完成连接。
为什么用了 Shutdown 还有 goroutine 泄漏？检查你的 defer 和 channel
常见泄漏点不是 server 本身，而是启动时 spawn 的后台 goroutine —— 它们往往忽略退出信号，或阻塞在 select 的无缓冲 channel 上。
- 启动定时任务（如 metrics 上报）必须接收
ctx.Done()：select { case - 用
sync.WaitGroup等待 goroutine 退出时，Wait()必须在 shutdown 流程末尾调用，且所有 goroutine 都要确保能收到退出通知 - 避免在 defer 中起 goroutine：
defer func() { go cleanup() }()会导致 cleanup 可能运行在 main goroutine 退出之后 - 数据库连接池、gRPC 连接池等，shutdown 时调
Close()或Reset()，否则底层连接不会释放
测试优雅停机是否生效？别只看日志，要看连接状态
本地跑 kill -TERM $(pidof myservice) 看日志是否打印 “shutting down…” 不够，真正要验证的是连接是否被真正 drain。
- 用
netstat -an | grep :8080（或对应端口）观察 ESTABLISHED 连接数是否归零，TIME_WAIT 是否缓慢上升（说明连接正常关闭） - 对 gRPC 服务，用
grpcurl持续发请求，直到收到rpc error: code = Unavailable desc = server stopped，而不是connection refused或超时 - 在 shutdown 前加
log.Println("active connections:", httpServer.ConnState)（需自定义 ConnState hook）可粗略统计活跃连接 - Kubernetes 环境下，务必设置
terminationGracePeriodSeconds≥ shutdown 超时时间，否则 kubelet 会在你 shutdown 完成前发SIGKILL
最麻烦的永远不是写 shutdown 逻辑，而是确认每个第三方库的 client 是否提供了 Close 方法、是否真的释放了底层 net.Conn —— 这些细节一漏，就变成“看起来优雅，实则连接堆积”。
