gin默认关机不优雅是因为router.run()直接调用http.listenandserve()，阻塞且不监听信号、不调用shutdown()，导致sigterm/sigint触发时正在处理的请求被强制中断；必须手动构造http.server、监听sigint/sigterm、用带超时的context调用shutdown()，并显式关闭ticker、db、redis等所有goroutine资源，漏掉任一环节进程即卡住。
为什么Gin默认关机不是“优雅”的
Gin本身不内置优雅关机逻辑，http.Server 的 Shutdown() 方法才是关键。如果你只写 router.Run(":8080")，进程收到 SIGTERM 会直接退出，正在读取 body、写响应、甚至刚进中间件的请求全被丢弃。这不是 Gin 的缺陷，而是 Go 标准库的默认行为：它不监听信号，也不自动调用 Shutdown()。
怎么手动实现Gin的优雅关机
核心是捕获 SIGTERM 和 SIGINT，然后调用 http.Server.Shutdown() 并等待完成。常见错误是只调用 srv.Close() —— 这会立刻关闭 listener，新连接拒绝，但**正在处理的请求不会等完**，和粗暴 kill 几乎没区别。
- 必须用
srv.Shutdown(ctx)，传入带超时的context.Context -
Shutdown()会先关闭 listener，再逐个等待活跃连接完成（包括长连接、流式响应） - 超时时间建议设为略小于 k8s 的
terminationGracePeriodSeconds（比如设 25s，k8s 设 30s） - 务必在
Shutdown()前停止向服务注册中心注销（如 Nacos），否则流量还在打，而 listener 已关
示例关键片段：
srv := &http.Server{
Addr: ":8080",
Handler: router,
}
go func() {
if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
log.Fatal(err)
}
}()
<p>quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
</p><p>ctx, cancel := context.WithTimeout(context.Background(), 25*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
log.Fatal("server shutdown error:", err)
}
</p>
K8S里preStop + readinessProbe怎么配合Gin关机
光靠 Go 代码不够。K8S 的 preStop 钩子和 readinessProbe 必须协同，否则流量还在打，Gin 却已开始 Shutdown，请求照样失败。
-
readinessProbe必须返回失败（比如健康检查接口返回 503 或改 path），让 Service 立刻摘掉该 Pod 的 endpoints —— 这步要**早于**preStop执行 -
preStop不该做耗时操作（如 sleep），推荐用 HTTP 请求触发 Gin 内部的“准备关机”状态（比如设置一个 flag，让中间件快速拒绝新请求） - 如果用 exec 方式执行
preStop，注意 Alpine 镜像里可能没有curl，需提前安装或换用wget -
terminationGracePeriodSeconds必须 ≥ Go 代码中Shutdown()的超时 +preStop执行时间，否则 SIGKILL 会提前到来
典型 Deployment 片段：
lifecycle:
preStop:
httpGet:
path: /shutdown-ready
port: 8080
readinessProbe:
httpGet:
path: /healthz
port: 8080
# 当 /healthz 返回非2xx时，立即移除endpoint
terminationGracePeriodSeconds: 30
容易被忽略的连接类型陷阱
HTTP/1.1 短连接一般没问题，但以下场景极易出问题：
- WebSocket 连接：Gin 默认不管理 ws 生命周期，
Shutdown()不会主动 close ws conn，需自己监听srv.RegisterOnShutdown()或在 handler 里加 context.Done() 检查 - 流式响应（如 SSE、大文件下载）：
Shutdown()会等它们写完，但如果客户端断连或网络卡住，可能阻塞超时；建议在 handler 中加写超时（conn.SetWriteDeadline()） - 数据库长事务或慢查询：应用层关机不等于 DB 层事务回滚，必须确保 ORM（如 GORM）支持 context 传递，并在
Shutdown()前 cancel 相关 context - 异步任务（如 goroutine 启动的定时 job）：需提供显式 stop 方法，并在
Shutdown()里调用，否则它们可能继续运行甚至 panic
真正难的不是写几行 Shutdown()，而是厘清所有外部依赖的生命周期边界 —— 它们是否响应 context？有没有自己的 shutdown hook？是否需要额外同步？这些细节不处理，优雅就是假象。
