直接 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() 方法。关键步骤如下：
- 用
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() 还在跑，被强制中止。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须在
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() 捕获。
立即学习“go语言免费学习笔记（深入）”；
- 所有中间件内启的 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() 返回就退出的事务，都足以让平滑关闭失效。 
