Go微服务必须用http.Server.Shutdown配合带超时的context.Context，否则会丢请求、卡进程、漏关资源；直接os.Exit或kill-9会导致连接重置、事务中断、缓存丢失和注册中心残留；Shutdown先拒新连接再等活跃连接结束，需设合理超时并统一协调DB/MQ/gRPC等组件退出。
Go 微服务必须用 http.Server.Shutdown 配合带超时的 context.Context，否则会丢请求、卡进程、漏关依赖资源——这不是可选优化，而是生产环境底线。
为什么不能直接调用 os.Exit 或 kill -9
硬终止会导致客户端收到 connection reset，正在执行的数据库事务中断，缓存写入丢失，甚至注册中心残留僵尸实例。而 http.Server.Shutdown 是 Go 标准库唯一明确支持的优雅退出方式：它先让监听器拒绝新连接（Accept 返回 http.ErrServerClosed），再等待活跃连接自然结束或超时。
- 常见错误现象：
panic: http: Server closed—— 通常不是 Shutdown 出错，而是其他 goroutine 还在往已关闭的 server 写响应 -
srv.Close()和srv.Shutdown()不是等价操作：Close()只关闭 listener，不等连接；Shutdown()才真正做“等待” - 别在
defer里关 DB 或 MQ：main 函数在Shutdown后就退出了，defer来不及执行
http.Server.Shutdown 必须配 context.WithTimeout
传 context.Background() 或没设超时的 context.WithCancel 会导致 Shutdown 无限等待——只要有一个连接卡住（比如死循环、阻塞 I/O、没设下游超时），整个进程就 hang 住。
- 超时值不是拍脑袋定的：取业务最长请求耗时的 1.5–2 倍，普通 HTTP 服务建议 10–30 秒；含长轮询或流式接口的，得按实际最大响应时间设
- 错误示例：
srv.Shutdown(context.Background())→ 可能永远不返回 - 正确写法：
ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second); defer cancel(); srv.Shutdown(ctx) -
Shutdown返回非 nil 错误（如context.DeadlineExceeded）只表示“没等完”，不是 panic 级别问题，应记录日志但继续执行后续清理
如何协调 DB、MQ、gRPC 等多组件同步退出
HTTP server 只是入口，真正耗时的是下游依赖。必须统一用一个退出信号源驱动所有组件，而不是各自调 Shutdown 或 GracefulStop。
- 主 goroutine 创建共享
ctx, cancel := context.WithTimeout(...)，所有可关闭组件（*sql.DB、*grpc.Server、*amqp.Connection、自定义 worker pool）都接收该 ctx 并监听ctx.Done() - 关闭顺序必须反向依赖：先停消息消费者（不再拉新任务）→ 再等 DB 连接池空闲（
db.Stats().OpenConnections == 0）→ 最后关 HTTP server -
grpc.Server.GracefulStop()和http.Server.Shutdown()行为不同：前者会等所有活跃 RPC 完成并关闭 listener；后者只等 HTTP 连接，不关 listener（需手动srv.Close()或靠 Shutdown 内部触发） - 别在工厂函数里启动 signal 监听 goroutine——信号捕获必须由主程序统一处理，工厂只暴露
Start()/Stop()接口
signal.Notify 必须同时监听 SIGINT 和 SIGTERM
Kubernetes 发 SIGTERM，本地 Ctrl+C 发 SIGINT，两者语义一致且都该触发停机流程。分开监听或只监听其一，会导致容器环境下无法正常终止。
- 正确写法：
quit := make(chan os.Signal, 1); signal.Notify(quit, os.Interrupt, syscall.SIGTERM) - channel 必须带缓冲（至少 size=1），否则首个信号可能丢失
- HTTP server 必须启动在单独 goroutine，否则
srv.ListenAndServe()会阻塞主 goroutine，导致信号监听逻辑卡住 - 检查
srv.ListenAndServe()返回值：仅当等于http.ErrServerClosed才是正常关闭；其他错误（如端口被占）要记录并退出
最容易被忽略的点是：Shutdown 不等于“万事大吉”。它只管 HTTP 连接，不管 goroutine 泄漏、定时器未停、文件句柄未释放——这些都得在 Stop 流程里显式处理，而且每个 Close 方法本身也得支持上下文超时，否则照样卡死。
