生产环境必须同时监听 sigterm 和 sigint 以支持优雅关闭，仅监听 sigint 会导致容器或 systemd 下强制终止；shutdown 前需先关闭 listener，context 超时应比平台终止宽限期短 5s，并排查 goroutine 泄漏。
为什么 signal.Notify 不能只监听 SIGINT 就收工
生产环境里，SIGINT（Ctrl+C）只是个开发调试信号；真正上线后，进程大概率被 SIGTERM 终止（比如 systemd、K8s 的 kill -15）。只监听 SIGINT 会导致服务在容器或 systemd 下无法优雅退出，直接被强制杀掉。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须同时监听
SIGTERM和SIGINT，两者行为一致，都走优雅关闭流程 - 避免监听
SIGHUP或SIGUSR1等非标准终止信号，除非你明确要支持热重载等扩展行为 - 不要用
signal.Ignore屏蔽其他信号——它可能干扰 runtime 内部信号处理（如SIGQUIT用于 panic trace）
http.Server.Shutdown 调用前必须先关掉 listener
http.Server.Shutdown 是阻塞的，但它不会自动停掉底层 listener。如果 listener 还开着，新连接仍可能被 accept 进来，而此时 handler 已开始拒绝请求，导致连接半开、超时或 503 混乱。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 调用
srv.Shutdown前，先执行ln.Close()（其中ln是你传给srv.Serve的net.Listener） - 推荐用
net.Listen显式创建 listener，而不是直接传地址给http.ListenAndServe，否则拿不到ln实例 - 注意：
srv.Close()是粗暴关闭（立即断连），不是优雅关闭，别误用
Context 超时时间必须短于系统级 kill timeout
很多部署环境（如 Kubernetes、systemd）会在发 SIGTERM 后等待固定时间（如 30s），超时就发 SIGKILL 强制终止。如果你设的 context.WithTimeout 是 60s，服务大概率被硬杀，根本来不及完成 Shutdown。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 设置 shutdown context 超时值 = 部署平台的 terminationGracePeriodSeconds − 5s（留出缓冲）
- 例如 K8s 设了
terminationGracePeriodSeconds: 30，代码里就用context.WithTimeout(ctx, 25*time.Second) - 不要依赖
http.Server.IdleTimeout替代 shutdown 超时——它只管空闲连接，不管正在处理的请求
goroutine 泄漏常藏在中间件或后台任务里
优雅关闭失败，十次有八次不是 Shutdown 本身的问题，而是某个 goroutine 卡在 I/O、channel receive 或无休止 for-select 循环里，导致 Shutdown 一直阻塞不返回。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 检查所有注册的中间件：是否启动了长生命周期 goroutine（如轮询、定时器）？它们是否接收并响应 shutdown 信号？
- 数据库连接池、消息队列消费者等外部依赖，必须显式调用其
Close方法，并确保它们也带 context 控制 - 用
runtime.NumGoroutine()在 shutdown 前后打日志，快速定位泄漏点
最麻烦的从来不是怎么写 shutdown 逻辑，而是得把所有“悄悄跑起来”的 goroutine 全揪出来，挨个加退出机制。没人替你记着那些匿名 go func 里有没有 select
