go微服务优雅停机需同时监听os.interrupt和syscall.sigterm，用带缓冲channel捕获信号；shutdown必须配合context.withtimeout设置合理超时（如25秒），避免卡死；下游资源须按反向依赖顺序手动关闭，否则导致panic或数据丢失。
Go 微服务的优雅停机不是“调个 Shutdown() 就完事”，而是信号捕获、HTTP 层排空、下游资源按序关闭三者必须咬合。漏掉任意一环，都会导致请求中断、goroutine 泄漏或进程卡死。
为什么 signal.Notify 必须同时监听 os.Interrupt 和 syscall.SIGTERM
本地开发按 Ctrl+C 触发 os.Interrupt，Kubernetes 删除 Pod 时发的是 syscall.SIGTERM。只监听其中一个，服务在一半环境里会直接硬退出。
-
signal.Notify的 channel 必须带缓冲：make(chan os.Signal, 1)，否则第一个信号可能丢失 - 不能把
signal.Notify放进 goroutine 里就不管——主 goroutine 必须显式阻塞等待信号，比如 - 不要监听
SIGHUP或SIGUSR1等无关信号，避免干扰主停机流程 - 收到信号后只执行一次停机逻辑；重复信号（如快速连按 Ctrl+C）应被忽略，靠 channel 缓冲 + 单次接收控制
http.Server.Shutdown() 超时设置的坑在哪
Shutdown() 本身不设超时，全靠传入的 context.Context 控制。传 context.Background() 或没设 deadline 的 context.WithCancel()，等于让服务无限等待卡死。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 超时值不能拍脑袋定：建议设为略大于业务 P99 请求耗时（如 15–30 秒），有长轮询或流式接口的，得按最长响应时间上调
- K8s 环境下，
terminationGracePeriodSeconds默认 30 秒，你的context.WithTimeout必须比它小至少 5 秒（如 25 秒），否则 K8s 强杀前清理根本跑不完 -
Shutdown()返回context.DeadlineExceeded是常见现象，说明有请求卡住——此时记录日志即可，不必 panic，更不能 fallback 到Close() - 调完
Shutdown()后必须立刻调cancel()，否则 context 泄漏，goroutine 持续监听ctx.Done()
哪些资源必须手动关，且顺序不能错
http.Server.Shutdown() 只管 HTTP 连接层，gRPC、DB、Redis、WebSocket、定时器这些全得你亲手关。顺序错了，轻则 panic，重则数据丢失。
- 关闭顺序必须反向依赖：先停消息消费者（如 Kafka/Sarama），再等 DB 连接池空闲（
db.Close()前可先db.SetMaxOpenConns(1)加速归还），最后关 HTTP server -
*sql.DB.Close()是阻塞操作，要确保此前已无新查询发起，否则会一直等 - gRPC server 用
grpcServer.GracefulStop()，不是Stop()；它不等流式 RPC 完成，所以需配合业务层超时和连接池主动断开 - WebSocket 连接不会被
Shutdown()自动等待，得自己维护sync.Map存活连接，收到 shutdown 信号后遍历调conn.Close() - 后台 goroutine（如 metrics 上报）必须监听统一
ctx.Done()，不能用time.Sleep硬等，也不能靠 defer —— defer 在函数退出时执行，main 已结束
最常被忽略的点是：Shutdown 不会自动关闭监听 socket，它只协调连接层面的 graceful 结束；而监听器真正关闭，依赖 srv.ListenAndServe() 返回 http.ErrServerClosed。这意味着启动 HTTP server 必须放在 goroutine 里，主 goroutine 才能腾出手来等信号、调 Shutdown、关资源——这个结构一旦写错，整个优雅停机就形同虚设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
