echo.Context 不管理 HTTP 客户端连接池，仅承载请求生命周期；发外调请求需显式配置 *http.Client 的 Transport，合理设置 MaxIdleConns、IdleConnTimeout、TLSHandshakeTimeout、ResponseHeaderTimeout 等参数，并全局复用 client 实例。
echo.Context 本身不管理 HTTP 客户端连接池
很多人误以为 echo.Context 提供了内置的 HTTP 客户端或连接复用能力——它没有。echo.Context 只是请求生命周期的载体，用于传递值、读写响应、解析参数等。真正发 outbound 请求时，你用的仍是标准库的 http.Client，它的连接池必须显式配置。
必须手动配置 *http.Client 的 Transport 参数
默认的 http.DefaultClient 使用的是未调优的 http.Transport，高并发下极易耗尽空闲连接或卡死在 net/http.(*persistConn).roundTrip。常见现象是 pprof 显示大量 goroutine 停在 runtime.gopark，但错误日志里却看不到 context deadline exceeded。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
-
MaxIdleConns和MaxIdleConnsPerHost必须设为合理正整数（如 100），否则连接不会复用 -
IdleConnTimeout建议设为 30–90 秒，太短导致频繁重连，太长会堆积无效连接 -
ForceAttemptHTTP2应设为true（Go 1.12+ 默认开启，但显式声明更安全） - 别漏掉
ResponseHeaderTimeout和ExpectContinueTimeout，它们和Timeout是独立控制项
超时必须分层设置，缺一不可
只设 http.Client.Timeout 是不够的。真实请求链路包含 DNS 解析、TCP 拨号、TLS 握手、请求发送、响应头读取、响应体读取等多个阶段，任一环节卡住都会拖垮整个 goroutine。
-
Timeout：总生命周期上限（推荐 5–10 秒） -
Transport.DialContext中嵌套net.Dialer.Timeout和KeepAlive（如 30 秒） -
Transport.TLSHandshakeTimeout（建议 5 秒） -
Transport.ResponseHeaderTimeout（建议 3 秒，防服务端迟迟不发 header） -
Transport.ExpectContinueTimeout（建议 1 秒，仅对带Expect: 100-continue的请求生效）
在 Echo handler 中复用 client 实例，而非每次 new
http.Client 是并发安全的，且内部已做连接池管理。你在全局或包级定义一个 client 变量即可，不要在每个 handler 里 new(http.Client) 或从 context.Value 取 client——后者容易引发泄漏或竞态。
- client 应在应用启动时初始化一次，例如放在
main()或init()函数中 - 避免把 client 存进
c.Set("client", ...)；echo.Context不是对象容器，长期持有 client 实例可能延长其生命周期 - 若需 per-request 隔离（如不同租户走不同代理），可用
context.WithValue包一层*http.Transport，而不是整个 client
ResponseHeaderTimeout 的 client，在某个下游接口返回 header 前就默默卡住了 3 分钟。 
