Echo 不内置优雅停机，必须手动监听 SIGTERM/SIGINT 并调用 e.Server.Shutdown() 配合超时 context，否则 kill -15 会强制中断连接、丢弃请求。
直接结论：Echo 本身不内置优雅停机逻辑，必须手动注册 SIGTERM / SIGINT 信号处理器，并配合 e.Server.Shutdown() 显式关闭 HTTP server，否则 kill -15 会立即中断连接，导致正在处理的请求被丢弃。
为什么 Echo 的 Start() 不支持优雅停机
Echo 的 Start() 是阻塞式调用，内部直接调用 http.Server.Serve()，没有监听系统信号、也没有封装 Shutdown() 流程。它等同于裸用 net/http —— 你得自己接管信号和关闭时机。
-
Start()启动后，进程对SIGTERM完全无感知，除非你提前注册 - 不调用
Shutdown()就直接退出，所有活跃连接（包括正在写响应的）会被 OS 立即重置，客户端收到connection reset或超时 - 即使设置了
ReadTimeout/WriteTimeout，也只影响单次读写，不控制整个 shutdown 窗口
标准实现：用 signal.Notify + Server.Shutdown()
核心是两件事：监听终止信号、触发带超时的 Shutdown()。以下是最小可靠模板：
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
package main
<p>import (
"context"
"os"
"os/signal"
"syscall"
"time"
"github.com/labstack/echo/v4"
"github.com/labstack/echo/v4/middleware"
)</p><p>func main() {
e := echo.New()
e.Use(middleware.Logger())
e.GET("/", func(c echo.Context) error {
time.Sleep(3 * time.Second) // 模拟长耗时处理
return c.String(200, "ok")
})</p><pre class="brush:php;toolbar:false;">srv := &http.Server{
Addr: ":8080",
Handler: e,
}
go func() {
if err := srv.ListenAndServe(); err != http.ErrServerClosed {
e.Logger.Fatal(err)
}
}()
// 监听 SIGTERM 和 SIGINT
quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGTERM, syscall.SIGINT)
<-quit
e.Logger.Info("Shutting down server...")
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
e.Logger.Error(err)
}}
-
srv.ListenAndServe()必须在 goroutine 中启动，否则会阻塞信号接收 -
context.WithTimeout的时间要大于你最长请求预期（比如 10s），否则未完成请求会被强制中断 - 不要在
Shutdown()前调用os.Exit()，否则Shutdown()无法执行
Kubernetes 场景下必须加 preStop 钩子
在 K8s 中，仅靠 Go 层信号处理还不够。容器收到 TERM 信号后，K8s 默认等待 30 秒（terminationGracePeriodSeconds）才发 KILL。但如果你的应用 shutdown 耗时超过这个值，或者依赖外部服务下线（如 Nacos/Eureka），就必须用 preStop 提前干预。
- 在 Pod spec 中配置
preStop，例如：exec: command: ["/bin/sh", "-c", "sleep 5"]，为 Echo 的Shutdown()争取缓冲时间 - 如果集成注册中心，
preStop应先调用 API 主动下线（如curl -X PUT http://nacos/v1/ns/instance?serviceName=xxx&ip=xxx&port=8080&enabled=false），再 sleep，最后才轮到 Go 进程收到SIGTERM - 务必确认
terminationGracePeriodSeconds≥preStop耗时 + Go 层Shutdown()超时，否则 K8s 会强杀
容易踩的坑：超时设置与连接泄漏
很多人以为只要调了 Shutdown() 就万事大吉，但实际常因底层资源未释放导致 hang 住或超时失败。
-
http.Server的IdleTimeout必须显式设置（如IdleTimeout: 30 * time.Second），否则空闲连接可能永远不关闭，拖慢Shutdown() - 若使用数据库连接池（如
sql.DB），需在Shutdown()后手动调用db.Close()，否则连接不会归还，Shutdown()可能因等待连接释放而卡住 - 第三方客户端（如 Redis、gRPC client）若持有长连接，也需在 shutdown hook 中显式
Close()，Echo 本身不管理这些 - 避免在
Shutdown()期间启动新 goroutine 或发起新网络请求 —— 此时程序已进入终态，行为不可控
真正可靠的优雅停机，从来不是加几行 signal 代码就能搞定的事；它要求你清楚每一层连接的生命周期，以及每个外部依赖的下线节奏。信号只是开关，关什么、怎么关、关多久，全得自己画线。
