Echo进程需手动监听SIGTERM，调用echo.Server.Shutdown()等待请求完成，再关闭数据库连接池；必须显式初始化http.Server而非用e.Start()，并确保db.Close()在Shutdown返回后执行，避免连接泄漏。
如何让Echo进程响应 SIGTERM 并安全退出
Go 程序默认不处理系统信号，直接 kill 会导致连接中断、事务丢失、连接池未归还。Echo 本身不内置信号监听，必须手动集成 os.Signal 和 echo.Server.Shutdown。
关键点是：不能只调用 e.Start() 后就阻塞，得用 server.Serve() 配合信号通道主动控制生命周期。
- 在
e.Start()前启动一个 goroutine 监听os.Interrupt和syscall.SIGTERM - 收到信号后，调用
server.Shutdown()，它会等待活跃 HTTP 请求完成（默认 30 秒超时） - 务必在
Shutdown()返回后再关闭数据库连接池（如db.Close()），否则可能 panic - 若使用
echo.New().Start()这种快捷方式，无法获取底层*http.Server实例，必须改用显式初始化
server := &http.Server{Addr: ":8080", Handler: e}
go func() {
if err := server.ListenAndServe(); err != http.ErrServerClosed {
log.Fatal(err)
}
}()
sig := make(chan os.Signal, 1)
signal.Notify(sig, os.Interrupt, syscall.SIGTERM)
<– 收到信号
<– 调用 server.Shutdown(context.WithTimeout(...))
<– db.Close()
<– os.Exit(0)
数据库连接池没释放干净的典型表现
服务重启后出现 dial tcp 127.0.0.1:5432: connect: connection refused 或大量 waiting for connection 日志，说明连接池没关，旧连接还在占着数据库资源，新进程连不上。
根本原因常是：只调用了 db.Close()，但没等空闲连接真正归还；或 db.SetMaxIdleConns(0) 后立即关池，导致 idle 连接来不及清理。
-
db.Close()是异步的：它只标记连接池为“关闭中”，已归还的连接会被立即关闭，但正在使用的连接会继续跑完 - 必须配合
server.Shutdown()的 context 超时，确保所有请求结束、连接归还完毕再调db.Close() - 生产环境建议设
db.SetConnMaxLifetime(30 * time.Minute)，避免长连接老化失效引发的偶发错误 - 不要把
sql.DB当成一次性的——它是线程安全的长期对象，应全局复用，而非每次请求 new
Echo + GORM 场景下连接池释放顺序怎么写
GORM v2 的 *gorm.DB 底层封装了 *sql.DB，但它的 Close() 方法只是透传给底层，所以释放逻辑和原生 sql.DB 一致，只是多一层封装。
最容易错的是：在 Echo 启动前就 defer db.Close()，结果服务刚起来就被关了；或者把 db.Close() 放在 main 函数末尾，根本等不到信号触发。
- 正确做法：把
db作为依赖注入进 Echo 的e.HTTPErrorHandler或自定义中间件，或通过全局变量/结构体字段持有 - 在信号处理 goroutine 中，先
server.Shutdown()，等它返回后再db.Close() - 如果用 GORM 的
Session或Transaction，确保它们都在请求生命周期内 commit/rollback 完毕，否则db.Close()会卡住 - 可加日志确认：在
db.Close()前打印db.Stats().OpenConnections，看到为 0 再执行
为什么 kill -USR2 在某些部署环境不生效
kill -USR2 是 Echo 社区约定的优雅退出信号，但它依赖框架内部注册了对应 handler。如果你用的是标准 http.Server + Echo Router 组合（比如 http.ListenAndServe(":8080", e)），那 USR2 根本没人监听——这是最常被忽略的前提。
只有当你用 e.Start() 或 e.StartServer() 启动时，Echo 才会自动注册 USR2 handler。但很多生产部署（尤其是容器化）会绕过这个入口，直接调 http.Server.Serve()。
- 容器中用
kill -USR2 1失效？大概率是因为进程 PID 1 没有 signal handler，且未启用--init或 tini - Docker 默认不转发信号给 PID 1，需显式配置
docker run --init或在ENTRYPOINT前加tini -- - Kubernetes 中，
terminationGracePeriodSeconds必须 ≥server.Shutdown超时时间，否则 kubelet 会在你 shutdown 完成前发KILL - 别依赖
USR2做唯一退出路径——始终保留SIGTERM的 fallback 处理逻辑
实际部署中，信号处理和连接池释放不是两个独立问题，而是一条链：信号进来 → HTTP 服务器停收新请求 → 等待旧请求完成 → 关闭数据库连接池 → 进程退出。任一环没对齐超时或顺序，就会出现连接泄漏或请求中断。尤其要注意容器 init 进程和 Kubernetes 的信号传递机制，它们经常悄无声息地吞掉你的 SIGTERM。
