直接 kill -15 会导致数据库事务中断，因未处理信号时 os.exit() 强制终止 goroutine；需用 http.server.shutdown() 配合 context 超时、显式关闭 db、cancel 后台 context、waitgroup 等协同实现平滑关闭。
为什么直接 kill -15 会导致数据库事务中断
收到 SIGINT 或 SIGHUP 时，若未做任何处理就让进程退出，os.Exit() 会立即终止所有 goroutine。正在执行的数据库事务、HTTP 响应写入、文件 flush 操作都会被强行打断，造成数据不一致或磁盘残留脏数据。Echo 本身不内置 shutdown 流程，必须手动接管信号监听和资源释放顺序。
如何用 http.Server.Shutdown() 安全关闭 Echo 服务
不能直接调用 e.Start() 启动，必须显式构造 http.Server 并绑定到 Echo 实例；否则无法调用 Shutdown() 方法。关键步骤如下：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 用
e.Server = &http.Server{Addr: ":8080", Handler: e}显式赋值，而非依赖e.Start()内部创建 - 启动前启动一个 goroutine 监听
os.Interrupt和syscall.SIGTERM - 收到信号后，调用
server.Shutdown()并传入带超时的context，例如context.WithTimeout(context.Background(), 10*time.Second) - 在
Shutdown()返回后，再显式关闭数据库连接池、取消后台任务 context、等待 goroutine 结束
echo.Server.Shutdown() 不会自动等待 DB 事务完成
http.Server.Shutdown() 只负责关闭 HTTP 连接并拒绝新请求，它对数据库连接池、事务、后台协程完全无感知。常见错误是以为调完 Shutdown() 就万事大吉，结果 db.Exec() 还在跑，被强制中止。
- 必须在
Shutdown()返回后，单独调用db.Close()（注意：不是sql.DB的Close()，而是你封装的事务管理器的清理方法） - 若使用
gorm.DB，需确保所有 pending transaction 已提交或回滚，再调db.Close() - 后台任务（如日志刷盘、指标上报）应接收一个
context.Context，并在主 shutdown 流程中cancel()它 - 用
sync.WaitGroup等待所有非守护型 goroutine 退出，避免进程提前结束
中间件里启动的 goroutine 容易被遗漏
有些中间件会在请求进入时 spawn goroutine 处理异步逻辑（比如审计日志、事件通知），这些 goroutine 往往持有 request-scoped context，但没做 cancel 传播。服务 shutdown 时它们可能还在运行，且不会被 Shutdown() 捕获。
- 所有中间件内启的 goroutine，必须接受一个可 cancel 的
context.Context，并在主 shutdown 时统一 cancel - 避免在中间件里直接用
go func() {}()，改用go func(ctx context.Context) {} (req.Context()) - 检查是否用了
echo.MiddlewareFunc包裹了未适配 shutdown 的旧逻辑——这类代码在 SIGTERM 下极易成为孤儿 goroutine
context.WithTimeout()、一个没被 WaitGroup.Done() 的 goroutine、一次没等 tx.Commit() 返回就退出的事务，都足以让平滑关闭失效。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
