Gin 本身无内置优雅关闭，需用 http.Server.Shutdown() 配合 signal 监听和 context 超时，手动管理所有 goroutine 退出；漏掉任一环节（如 ticker、DB、Redis 或子 goroutine 未响应 ctx.Done）将导致进程卡住。
直接说结论：Gin 本身没有内置优雅关闭逻辑，router.Run() 是阻塞式启动，无法手动干预；真正起作用的是标准库 http.Server 的 Shutdown() 方法，配合 os/signal 监听信号，再手动管理所有长期 goroutine 的退出——漏掉任何一环，“优雅”就只是假象。
为什么 router.Run() 不能用于优雅关闭
router.Run() 内部调用的是 http.ListenAndServe()，它会一直阻塞，直到发生错误或进程被强杀。你发 SIGINT（Ctrl+C）或 SIGTERM，程序直接退出，正在处理的请求被中断，连接被重置，数据库事务可能没提交，定时任务还在后台跑……根本谈不上“优雅”。
- 必须改用
http.Server显式构造服务实例，才能调用Shutdown() -
Shutdown()不会自动等待你的业务 goroutine，只管 HTTP 连接层 - 别在
Shutdown()后立刻os.Exit()，要等自定义清理完成
怎么用 http.Server.Shutdown() 配合信号监听
核心是三件事：启动服务、监听信号、触发关闭。关键细节全在 channel 缓冲和 context 超时上。
- 用
make(chan os.Signal, 1)创建带缓冲的 signal channel，否则首次信号可能丢失 - 只监听
syscall.SIGINT和syscall.SIGTERM，别加SIGHUP等无关信号 -
Shutdown()必须传入带超时的context.Context，比如context.WithTimeout(ctx, 10*time.Second)，防止卡死 - 调用
Shutdown()后，要select等待它返回，不能直接往下走
示例关键片段：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
srv := &http.Server{Addr: ":8080", Handler: router}
go func() {
if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
log.Fatalf("listen: %v", err)
}
}()
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
<-sigChan
log.Println("shutting down server...")
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
log.Fatalf("server shutdown failed: %v", err)
}
哪些 goroutine 容易被忽略导致进程卡住
HTTP Server 关了，不代表你的程序能退出。下面这些常见组件若没显式关，进程会 hang 住：
-
time.Ticker：必须在select中监听ctx.Done()，不能只轮询ctx.Err()（会忙等） - 数据库连接池（如
sql.DB）：调db.Close()，它会等所有活跃连接归还后再返回 - Redis 客户端（如
redis.Client）：调client.Close()，否则底层连接不释放 - 消息消费者（如 Kafka/NATS）：需调用对应 client 的
Close()或发送 stop signal - 健康检查上报 goroutine：必须接收
ctx.Done()并主动 return，不能靠 GC 清理
验证方法很简单：启动后发一个慢请求（curl "http://localhost:8080/slow" &），再 Ctrl+C，然后 ps aux | grep yourapp —— 如果进程还在，说明有 goroutine 没退出。
context 传递和取消链路怎么组织才可靠
所有长期运行的 goroutine 必须从同一个 root context 派生，并在内部用 select 响应 ctx.Done()。别用 context.Background() 直接传进去，那等于放弃控制权。
- 主函数创建
ctx, cancel := context.WithCancel(context.Background()) - 把
ctx传给所有子 goroutine，包括定时任务、消费者、健康检查等 - 在 signal 处理分支里调
cancel()，所有监听该 ctx 的 goroutine 就会同时收到通知 - 不要用普通 channel 替代 context —— 没超时、没层级取消、不兼容第三方库
最危险的坑是：goroutine 里开了新 goroutine 却没传 context，或者用了 time.AfterFunc 这类不响应 cancel 的 API。这类代码看起来“能跑”，但关不掉。
