os.Interrupt 信号不能直接退出服务，因为立刻调用 os.Exit() 会强行中断数据库事务、HTTP 请求写入和文件操作，导致数据丢失或状态不一致；Gin/echo/fiber 等框架默认不处理 shutdown，需手动监听信号并协调资源释放；应使用 http.Server.Shutdown() 配合超时 context 安全关闭连接，并同步等待 DB 事务与后台任务完成。
为什么 os.Interrupt 信号不能直接退出服务
收到 SIGINT 或 SIGHUP 时立刻调用 os.Exit()，会导致正在执行的数据库事务、HTTP 请求写入、文件写操作等被强行中断，数据丢失或状态不一致。Gin/echo/fiber 等框架默认不处理 shutdown 流程，必须手动接管信号监听与资源释放顺序。
如何用 http.Server.Shutdown() 安全终止 HTTP 连接
http.Server.Shutdown() 是标准库提供的优雅停机核心方法，它会关闭监听端口、拒绝新连接，并等待已有请求完成（默认无超时），但不会自动等待后台 goroutine 或 DB 事务结束 —— 这部分必须显式协调。
- 调用前需确保所有 handler 已注册完毕，且未启动其他监听逻辑
- 务必传入带超时的
context.Context，否则可能无限等待卡死，例如：ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second) - 调用
srv.Shutdown(ctx)后，应检查返回错误：if err != nil && err != http.ErrServerClosed才真正异常 - 不要在
Shutdown()之后再调用srv.Close()，会 panic
如何同步等待 DB 事务和后台任务完成
数据库连接池关闭、长事务提交、消息队列确认等，无法被 http.Server.Shutdown() 自动感知，需配合 sync.WaitGroup 或 context 传播取消信号。
- 启动时用
sync.WaitGroup记录活跃事务 goroutine，每个事务结束时wg.Done()；停机时调用wg.Wait()阻塞直到全部完成 - 对支持 context 的 DB 驱动（如
pgx/v5），把 shutdown context 传递给db.BeginTx(ctx, ...)和tx.Commit(ctx)，确保超时后自动 rollback - 避免在 shutdown 流程中新开 goroutine，否则
WaitGroup无法追踪 - 若使用 GORM，注意
db.Close()不等待未提交事务，需先手动tx.Commit()或tx.Rollback()
完整信号监听与停机流程示例
以下是一个最小可行的 shutdown 脚本结构（以 Gin + pgx 为例）：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
go func() {
<-sigChan
log.Println("received shutdown signal")
// 1. 停止 HTTP 服务
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil && err != http.ErrServerClosed {
log.Printf("HTTP shutdown error: %v", err)
}
// 2. 关闭数据库连接（需先确保所有事务已结束）
if db != nil {
if err := db.Close(); err != nil {
log.Printf("DB close error: %v", err)
}
}
log.Println("server stopped")
os.Exit(0)
}()
log.Println("server started on :8080")
if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
log.Fatalf("server start error: %v", err)
}
关键点在于：信号监听必须在 ListenAndServe() 之前启动；Shutdown() 和 db.Close() 的顺序不能颠倒；所有异步资源清理必须在 os.Exit() 前完成。
事务是否真正落盘，取决于你是否在 handler 内显式 commit 并等待完成 —— 框架本身不替你做这件事，也不保证“最后一条 SQL 一定写入磁盘”。
