go微服务优雅停机需四步严丝合缝：信号捕获（同时监听os.interrupt和syscall.sigterm）、请求排空（http.server.shutdown配合context.withtimeout）、资源释放（db/grpc/consul等统一close）、顺序协调（反向依赖关闭）；缺一环即导致进程被sigkill强杀。
Go 微服务里，优雅停机不是“加个 Shutdown 就完事”，而是信号捕获、请求排空、资源释放、顺序协调四件事必须咬合严丝合缝；服务治理也不是堆一堆库，而是注册发现、熔断限流、链路追踪这些能力得嵌进生命周期里，否则停机时 Consul 还没注销、gRPC 流还在发、Hystrix 熔断器卡在半开状态——进程早被 SIGKILL 强杀了。
signal.Notify 必须同时监听 os.Interrupt 和 syscall.SIGTERM
只监听 SIGTERM，本地 Ctrl+C 会直接退出；只监听 os.Interrupt，K8s 里根本收不到信号。两者语义不同但行为一致：都该触发一次停机流程。
- 用
make(chan os.Signal, 1)创建带缓冲通道，防多信号丢失（比如 K8s 先发 SIGTERM，几毫秒后又补一个） -
signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM)必须写在http.ListenAndServe()或grpc.Server.Serve()之前，否则主 goroutine 已退出，信号无处可送 - 别在 goroutine 里调
signal.Notify后就 return —— 主函数得阻塞等信号，例如
http.Server.Shutdown() 必须传 context.WithTimeout，不能用 context.Background()
http.Server.Shutdown() 本身不设超时，传 context.Background() 就等于挂起等待，哪怕有个数据库查询卡死在没设 deadline 的 db.QueryRow() 上，进程就永远停不下来。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 超时值建议设为略大于业务 P99 延迟，常见是
20 * time.Second～30 * time.Second - K8s 环境下必须比
terminationGracePeriodSeconds小 5–10 秒，否则系统强杀前你的清理逻辑根本跑不完 - 调用前确保已停止
srv.ListenAndServe()的 goroutine，否则 Shutdown 可能被阻塞 - 返回
context.DeadlineExceeded不代表失败，只是说明有请求没来得及结束，日志记一下即可
gRPC Server.GracefulStop() 不等于“等所有请求完成”
GracefulStop() 会关闭 listener、拒绝新请求，但它只等 accept loop 结束，对正在跑的流式 RPC（stream）或长时间 unary 调用完全不感知——客户端可能还在收数据，服务端进程却已退出，报 transport is closing。
- 必须手动管理流式连接的生命周期：在 handler 里监听
ctx.Done()，收到信号后主动关闭 stream 发送端 - 后台 goroutine（如心跳上报、指标推送）必须用
select { case 退出，不能靠 sleep 或无缓冲 channel 阻塞 - 若用了 gRPC 客户端连接池，停机前需调
conn.Close()，否则底层 TCP 连接残留会拖慢整体 shutdown
服务治理组件的关闭必须纳入统一 shutdown 流程
Consul 注册、Nacos 配置监听、Hystrix 熔断器、OpenTelemetry SDK —— 这些不是启动时 new 出来就完事的，它们都有自己的清理逻辑，漏掉一个，进程就卡住或状态错乱。
- Consul client 关闭要调
client.KV().DeleteTree(...)主动注销服务，再调client.Close() - Nacos config client 需调
client.Shutdown()（或类似方法），否则配置监听 goroutine 会持续运行 - Hystrix 熔断器本身无 Close 方法，但如果你封装了自定义 fallback 或 metrics reporter，它们得在 shutdown 时显式停掉
- OpenTelemetry 的
traceProvider.Shutdown()和metricProvider.Shutdown()必须调，否则未 flush 的 span 会丢失
最常被忽略的点是：shutdown 不是“关服务”，而是“关依赖”。HTTP 和 gRPC server 只是门面，真正卡住进程的往往是那个忘了监听 ctx.Done() 的定时上报 goroutine，或是没设 deadline 的数据库查询。所有可关闭资源必须暴露 Close() 或 Shutdown() 方法，并按反向依赖顺序执行——先停业务入口，再断下游连接，最后清本地状态。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
