Gin 的 r.Run() 不能用于生产微服务，因其内部调用阻塞式 http.ListenAndServe()，无信号监听与上下文控制，收到 SIGTERM/Ctrl+C 会立即退出，导致请求中断、连接重置、事务未提交、注册中心未反注册等；必须显式构造 *http.Server，配合 signal.Notify 监听信号、context.WithTimeout 控制超时、srv.Shutdown() 等待连接结束，并手动关闭 DB/Redis/gRPC 等依赖资源。
为什么 Gin 默认的 r.Run() 不能直接用于生产微服务
它内部调用的是 http.ListenAndServe()，没有信号监听逻辑，收到 SIGTERM 或 Ctrl+C 会立即退出，正在处理的请求被强制中断，连接重置，客户端拿到 EOF 或超时错误。这不是“优雅”，是“猝死”。
微服务场景下尤其危险：注册中心来不及反注册、数据库连接未释放、日志缓冲未刷盘、gRPC 流未关闭——这些都会在日志里留下 context canceled、use of closed network connection 等错误。
- 必须自己构造
*http.Server实例，接管监听和关闭流程 - Go 1.8+ 原生支持
Shutdown()，无需第三方库（除非你要热重启） -
gin.Default()只负责路由和中间件，不控制生命周期
用 http.Server.Shutdown() 实现标准优雅停机
核心是三步：启动监听、监听系统信号、收到信号后调用 Shutdown() 并等待完成。关键不是“怎么关”，而是“等什么”。
Shutdown() 本身只做两件事：停止接受新连接、等待已有连接自然结束。但它**不会等你自定义的清理逻辑**（比如注销 Consul、关闭 DB 连接）。这些必须手动加在 Shutdown() 调用之后、os.Exit() 之前。
- 用
os/signal.Notify()监听os.Interrupt和syscall.SIGTERM -
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)控制最大等待时间，避免卡死 - 调用
srv.Shutdown(ctx)后，立即执行你的清理函数（如db.Close()、consul.Deregister()） - 最后才
cancel()和os.Exit(0)
示例关键片段：
srv := &http.Server{
Addr: ":8080",
Handler: router,
}
go func() {
if err := srv.ListenAndServe(); err != http.ErrServerClosed {
log.Fatal(err)
}
}()
quit := make(chan os.Signal, 1)
signal.Notify(quit, os.Interrupt, syscall.SIGTERM)
<-quit
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
log.Fatal("server shutdown error:", err)
}
// 此处放你的清理逻辑，比如 global.DB.Close()
log.Println("server exited")
热重启（零停机更新）要额外处理套接字继承
如果需求是“发版不中断连接”，Shutdown() 不够——它只是关旧进程，没启新进程。这时候得靠 endless 或手写 fork + 文件描述符传递。但注意：endless 已多年未维护，Go 1.16+ 的 os/exec.SysProcAttr 配合 net.FileListener 更可控。
-
endless依赖LISTENER_FD环境变量和固定文件描述符号（3），与容器环境或 systemd 冲突概率高 - Kubernetes 中更推荐用 readiness probe + preStop hook 配合原生
Shutdown()，而非热重启 - 真正需要热重启的场景极少：通常是遗留系统无法容忍秒级中断，且运维链路不支持滚动更新
简单判断：如果你用的是 Docker + K8s，优先走标准优雅停机；只有裸机部署且 SLA 要求毫秒级连续性，才考虑 endless 或自研热重启。
配置加载和日志初始化必须在 Shutdown() 之前完成
很多团队把 viper.ReadInConfig() 或日志轮转器（如 rotatelogs.New()）放在 main() 开头，看似没问题，但一旦 Shutdown() 流程中要写日志或读配置（比如注销前上报状态），就可能 panic——因为这些对象还没初始化，或者初始化失败被忽略。
- 所有依赖项（DB、Consul client、log、config）必须在
srv启动前初始化完毕 - 尤其注意
rotatelogs.New()返回的io.Writer如果初始化失败，gin.DefaultWriter = io.MultiWriter(...)会静默吞掉错误，导致后续日志全丢 - 建议在
Shutdown()前加一层检查：比如if global.Log != nil { global.Log.Info("shutting down...") }
最容易被忽略的一点：Shutdown() 的 context timeout 是针对 HTTP 连接的，不是为你自己的清理逻辑计时的。如果你的 DB 关闭要 45 秒，而 context 只给 30 秒，Shutdown() 会提前返回错误，但你的清理代码仍在后台跑——这会造成资源泄漏。务必分开控制。
