管理员安全退出指gin服务进程收到SIGTERM或SIGINT信号时，调用http.Server.Shutdown()等待HTTP请求完成后再退出，并依次关闭数据库、Redis等非HTTP资源，而非直接os.Exit()。
管理员安全退出不是指“用户登出”，而是指 gin 服务进程自身在收到终止信号（如 SIGTERM 或 Ctrl+C）时，不粗暴杀掉正在处理的请求，而是等它们完成、释放资源后再退出——这才是真正对管理员/运维友好的“安全退出”。
为什么直接调用 os.Exit() 是危险的
很多初学者会在 signal.Notify 回调里直接写 os.Exit(0)，这会导致：
- 正在写的 HTTP 响应被截断，客户端收到
connection reset或空响应 - 数据库连接、文件句柄、第三方连接池未关闭，可能引发泄漏或下游超时
- 注册中心（如 Consul/Etcd）来不及注销，其他服务继续往已死节点发请求
Go 标准库的 http.Server.Shutdown() 才是正确入口，它会主动关闭 listener，并等待现存连接自然结束（或超时）。
http.Server.Shutdown() 必须配合 context 使用
Shutdown() 是阻塞调用，必须传入带超时的 context.Context，否则可能永远卡住。常见错误是只传 context.Background() —— 它没有超时，一旦某个请求 hang 住，整个退出就卡死。
推荐写法：
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
log.Printf("Server shutdown error: %v", err)
}
注意：10s 不是越长越好。业务请求平均耗时 2s，设 5s 就够；若含长轮询或流式接口，需按最长预期等待时间设定。
必须手动清理非 HTTP 资源
Shutdown() 只管 HTTP 连接，不管你的数据库连接池、Redis 客户端、消息队列消费者、定时任务等。这些都得在 Shutdown() 后显式关闭：
- 调用
db.Close()（*sql.DB） - 调用
redisClient.Close() - 调用
timer.Stop()或发送停止信号给 worker goroutine - 若用了服务注册（如
registry.Deregister()），这里执行注销
顺序很重要：先 Shutdown() 等 HTTP 请求结束，再关依赖资源。反着来可能导致 handler 里访问已关闭的 DB 报 panic。
信号监听要覆盖 SIGTERM 和 SIGINT
容器环境（如 Kubernetes）发的是 SIGTERM，本地开发常用 Ctrl+C（即 SIGINT）。只监听一个，另一场景就会 fallback 到硬退出。
标准写法：
quit := make(chan os.Signal, 1) signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM) <-quit // 阻塞等待任一信号
别漏掉 syscall.SIGTERM，否则 K8s kill -15 会直接 kill 进程，跳过所有优雅逻辑。
真正容易被忽略的点：Shutdown 超时时间必须和业务最长请求耗时对齐，且所有非 HTTP 资源的关闭逻辑必须放在 Shutdown 返回之后——早一秒关，就可能让还在跑的 handler panic；晚一秒关，又拖慢整体退出节奏。
