必须全局复用并显式调优http.Client：设Timeout=10s、MaxIdleConns=200、MaxIdleConnsPerHost=200、IdleConnTimeout=90s、启用TLS会话复用，禁用默认client及handler内新建client。
为什么 Echo 里用 http.Get 会拖慢整个服务
不是 Echo 框架的问题，而是你每次调用 http.Get 都新建了一个未配置的 http.Client，它背后默认的 http.Transport 会迅速吃光连接资源：每个域名最多只缓存 MaxIdleConnsPerHost = 2 个空闲连接，10 个并发请求就排队；IdleConnTimeout 实际为 0，连接容易被服务端静默关闭，复用时触发重连；HTTPS 请求还不做 TLS 会话复用，每次握手耗时翻倍。
如何配置一个真正可复用的 http.Client 实例
必须全局定义、一次初始化、全程复用。关键不是“有没有 Client”，而是 Transport 是否显式调优：
-
Timeout设为 10 秒，避免单个慢请求拖垮 goroutine 池 -
DialContext套&net.Dialer{Timeout: 5 * time.Second, KeepAlive: 30 * time.Second}，防 DNS 卡顿和连接僵死 -
MaxIdleConns和MaxIdleConnsPerHost都设为 200，确保高并发下连接不排队 -
IdleConnTimeout: 90 * time.Second，比默认更长但不过度占用 fd -
TLSClientConfig.ClientSessionCache必须启用，用tls.NewLRUClientSessionCache(100)
别在 handler 里 new(http.Client)，也别直接用 http.DefaultClient——它共享全局 Transport，一旦被某处误改配置，全服务受影响。
HTTP/2 下连接复用失效的典型表现
即使你用了 ListenAndServeTLS 启用了 HTTP/2，客户端（比如微服务间调用）若没配对 Transport，依然会退化成“每 Host 一个 TCP 连接”。验证方式很简单：curl -I --http2 https://your-api/ping 看响应头是否真为 HTTP/2 200；再用 lsof -i :443 观察 ESTABLISHED 连接数是否随并发线性增长——如果是，说明复用没生效。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
-
ForceAttemptHTTP2默认就是true，不用手动设 - 删掉
TLSConfig.NextProtos或只留[]string{"http/1.1"}，会强制降级 MaxIdleConnsPerHost 会让连接池按 Host 隔离，彻底失去多路复用意义
中间件或 handler 里读取 c.Request().Body 的风险
这是最隐蔽的连接复用破坏点：如果你在鉴权中间件里调用 io.ReadAll(c.Request().Body)，又没把 body 放回去（http.MaxBytesReader 或 bytes.NewReader 包装），后续 handler 就读不到数据，c.Bind() 失败、c.FormValue() 返回空——而错误日志可能根本没打出来。
- 需要解析 body 时，优先用
c.Bind()，它内部已处理好 body 复用逻辑 - 必须手动读取时，用
body, _ := io.ReadAll(c.Request().Body)后，立刻重建：c.Request().Body = io.NopCloser(bytes.NewReader(body)) - 大文件上传场景，直接用
c.FormFile()，它绕过内存全量加载，不碰Request.Body
连接复用不是开了就行，它依赖 Transport 配置、TLS 缓存、HTTP/2 协商、甚至 body 是否被安全消费——任何一个环节断掉，性能就掉回 HTTP/1.1 水平。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
