错误：直接在中间件中对c.context()调用context.withtimeout()会干扰echo内部逻辑；正确做法是在handler内用c.request().context()派生子context并defer cancel()，或配置http.server的readheadertimeout、idletimeout、writetimeout全局超时。
中间件里用 context.WithTimeout 会干扰 Echo 内部逻辑
直接在中间件中对 c.Context() 调用 context.WithTimeout() 是危险操作。Echo 的 c.Context() 已被框架包装过，外部取消它可能导致中间件链提前终止、日志丢失、甚至 panic。你看到的超时错误（如 context deadline exceeded）往往不是来自这里，而是 http.Server 底层直接断连——请求根本没走到你的中间件。
真正该配超时的地方是 http.Server 字段
全局请求生命周期控制必须落在 http.Server 实例上，Echo 只是它的封装。重点配这三个字段（Go 1.8+ 推荐）：
-
ReadHeaderTimeout：连接建立后，读完请求头的最大时间，防慢速攻击 -
IdleTimeout：HTTP/1.1 keep-alive 下两次请求间的最大空闲时间 -
WriteTimeout：从响应开始写入到写完的总耗时（不含读请求头/body）
示例配置：
e := echo.New()
server := &http.Server{
Addr: ":8080",
Handler: e,
ReadHeaderTimeout: 5 * time.Second,
IdleTimeout: 60 * time.Second,
WriteTimeout: 30 * time.Second,
}
server.ListenAndServe()
单个 handler 需要业务超时？在 handler 内部派生子 context
如果某个接口（比如调第三方 API 或查 DB）需要独立超时，必须在 handler 函数体内用 c.Request().Context() 派生：
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 务必用
c.Request().Context()，不是c.Context() - 一定要
defer cancel()，否则 goroutine 泄漏 - 下游调用（如
db.QueryContext()、http.Client.Do()）必须显式传入这个新ctx - 超时后返回
echo.NewHTTPError()，才能触发自定义HTTPErrorHandler
错误写法：ctx, _ := context.WithTimeout(c.Context(), 3*time.Second) —— 这会污染 Echo 自身 context。
中间件统一加超时？小心健康检查等免检接口被误杀
有人写一个“全局超时中间件”，结果 /healthz 接口也卡住 3 秒才返回，监控系统判定服务不可用。真实场景中必须排除特定路径：
- 用
c.Request().URL.Path判断是否跳过 - 或把超时逻辑下沉到具体 handler，而非中间件
- 更稳妥的是：只在关键业务 handler 内做，避免一刀切
复杂点在于，超时控制分三层：TCP 层（http.Server）、业务层（handler 内 context.WithTimeout）、下游依赖层（DB/HTTP 客户端自己的 timeout）。这三层不联动，各自生效，容易漏掉某一层的兜底。
