e.Start()无法触发优雅关闭，因其是阻塞调用且不暴露*http.Server实例，导致无法监听信号、调用Shutdown()，进程收到SIGTERM/SIGINT时直接退出，defer不执行、连接被RST、请求丢弃。
为什么 e.Start() 无法触发优雅关闭
Echo 的 e.Start() 是阻塞调用，内部直接调用 http.ListenAndServe()，不暴露 *http.Server 实例。进程收到 SIGTERM 或 SIGINT 时，Go 运行时默认立即退出，defer 不执行、HTTP 连接被 OS 强制 RST，正在写响应的请求直接丢弃。
常见错误现象包括：
- Ctrl+C 后日志戛然而止，没看到任何 shutdown 日志
- 客户端收到
connection reset by peer或超时 - 数据库连接未关闭、gRPC server 未停、WebSocket 连接未通知断开
必须手动构造 http.Server 并监听信号
放弃 e.Start()，显式创建 *http.Server，在 goroutine 中运行 ListenAndServe()，同时主 goroutine 留给信号监听和 Shutdown() 调用。
关键点：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
srv := &http.Server{Addr: ":8080", Handler: e}—— 必须保留该变量引用 -
go func() { if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed { log.Fatal(err) } }()——http.ErrServerClosed是Shutdown()正常返回的预期错误，不是异常 -
sigChan := make(chan os.Signal, 1)—— 缓冲大小为 1，防 K8s 等环境连续发信号时丢失第一个 -
signal.Notify(sigChan, syscall.SIGTERM, os.Interrupt)后必须显式接收：，不能只注册不消费
Shutdown() 必须带超时 context，不能用 context.Background()
srv.Shutdown() 只拒绝新连接，并等待所有 handler 返回；它本身不设超时。若某个 handler 卡在无 deadline 的 DB 查询、Redis 调用或空 select{} 上，就会永久阻塞。
正确做法：
- 用
ctx, cancel := context.WithTimeout(context.Background(), 25*time.Second)显式设上限 - 调完
srv.Shutdown(ctx)立即cancel()，防止 context 泄漏 -
srv.Shutdown()返回context.DeadlineExceeded是正常现象，说明有请求卡住，只需记录日志，不要 panic，更不要 fallback 到srv.Close()
HTTP 层之外的资源必须手动关，且顺序不能错
srv.Shutdown() 只管 HTTP 连接层。以下资源全得你亲手关：
-
*sql.DB：调db.Close()，放在srv.Shutdown()之后，但要在所有 handler 返回后（否则可能 panic） -
*grpc.Server：用GracefulStop()，非Stop()，避免强制断连 - WebSocket 连接池：需遍历主动发送 close frame，再等待
conn.Close()完成 - 后台 goroutine（如定时任务、消息轮询）：通过 channel 或
context.CancelFunc通知退出，并sync.WaitGroup.Wait()等待结束
漏关一个，进程就卡住；顺序错一个（比如先关 DB 再等 handler），handler 里 DB 操作会 panic 或事务丢失。
