直接 kill -9 会导致 Gin 服务丢请求，因其发送 SIGKILL 无法捕获，进程被强制终止，未完成请求（如读 body、写响应、数据库事务）全中断；应使用 http.Server.Shutdown() 配合监听 SIGINT/SIGTERM/SIGQUIT 信号，并设置合理超时（如 5s）、关闭非 HTTP goroutine 及资源。
为什么直接 kill -9 会让 Gin 服务丢请求
因为 kill -9 发送的是 SIGKILL，Go 进程完全无法捕获——它不给任何机会执行清理逻辑，正在读取 body、写响应、甚至刚进数据库事务的请求，全被硬中断。用户看到的是超时或 502，后台却是“钱扣了单没建”。http.Server.Shutdown() 就是为解决这个而生：它停止接受新连接，但会等已有连接处理完（或超时）再退出。
必须监听哪些信号才能覆盖常见关闭场景
生产环境里，你没法控制别人怎么关你的进程。K8s kubectl delete pod 发 SIGTERM，本地调试按 Ctrl+C 是 SIGINT，有些运维脚本还会用 SIGQUIT。这三者都得接住：SIGKILL 不用管（也管不了）。
signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM, syscall.SIGQUIT)- 别漏掉
SIGQUIT：某些容器平台或 systemd 服务会发它 - 别加
SIGKILL：加了也没用，signal.Notify会静默忽略
Shutdown() 的 context 超时设多少才合理
超时不是越长越好，也不是越短越安全。它代表“最多等多久，之后强制断开未完成请求”。设太短（比如 1 秒），可能把正常慢请求（如文件上传、支付回调）直接掐断；设太长（比如 30 秒），又拖慢发布节奏，尤其在滚动更新时影响服务就绪时间。
- 电商类接口常见耗时上限是 5–10 秒，建议从
5 * time.Second起步 - 如果用了长轮询或 WebSocket，需单独评估，
Shutdown()不管连接类型，只管 HTTP handler 返回 - 务必配
ReadTimeout和WriteTimeout（如15 * time.Second），否则慢客户端可能让连接永远 hang 住，超时失效
最容易被忽略的 goroutine 泄漏点
优雅关闭只管 http.Server，但你的业务代码很可能开了其他 goroutine：定时任务、消息消费、健康检查上报……这些不会被 Shutdown() 自动停掉，会导致进程卡住不退出。
立即学习“go语言免费学习笔记（深入）”；
- 所有长期运行的 goroutine 必须支持通过
context.Context取消（比如time.Ticker.C换成time.AfterFunc或手动 select ctx.Done() - 数据库连接池、Redis 客户端等要显式调
Close()，别指望 GC - 验证方法：启动服务后发一个慢请求（如
curl http://localhost:8080/ &），再Ctrl+C，看进程是否真退出（ps aux | grep yourapp）
Gin 本身不参与信号处理，所有逻辑都在标准库 http.Server 和 os/signal 里，但正因如此，细节全靠自己兜底——信号监听漏一个、超时设错、goroutine 忘关，都会让“优雅”变成“假装优雅”。
