为什么 http.DefaultClient 在高并发下容易耗尽连接
默认的 http.DefaultClient 底层用的是 http.DefaultTransport，它的连接池对每个 host:port 只保留最多 2 个空闲连接（MaxIdleConnsPerHost = 2），且总空闲连接数上限仅 100（MaxIdleConns = 100）。QPS 稍高一点，比如每秒发起 50+ 请求到同一个域名，就频繁新建 TCP 连接、触发 TIME_WAIT，甚至出现 dial tcp: lookup xxx: no such host 或 context deadline exceeded —— 实际不是超时，是连接卡在排队或 DNS 解析被阻塞。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远不要直接用
http.DefaultClient做长周期、中高并发的 HTTP 调用 - 自定义
http.Transport，显式控制连接复用行为 - 注意：
http.Client本身是协程安全的，一个实例可复用，无需每次 new
MaxIdleConns 和 MaxIdleConnsPerHost 怎么设才不翻车
这两个值不是越大越好。设太高会撑爆本地文件描述符（Linux 默认 ulimit -n 1024），导致 too many open files；设太低又起不到复用效果。关键看你的目标服务数量和单服务请求密度。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 如果只调一个后端（如内部 API），把
MaxIdleConnsPerHost设到 50～100，MaxIdleConns至少同步放大 - 如果调几十个不同域名（比如聚合第三方服务），优先保
MaxIdleConnsPerHost = 10～20，再把MaxIdleConns设为MaxIdleConnsPerHost × 域名数 × 1.5 - 必须配
IdleConnTimeout（推荐 30s），否则空闲连接永久驻留，NAT 网关或 LB 可能悄悄断连，下次复用时才发现read: connection reset by peer
HTTP/2 下 ForceAttemptHTTP2 有什么副作用
Go 1.6+ 默认开启 HTTP/2 支持，但前提是服务端也支持且 TLS 握手成功。手动设 ForceAttemptHTTP2 = true 并不会“强制升级”，而是在 HTTP/1.1 失败后多试一次，反而增加延迟；更危险的是，它会让客户端忽略服务端是否真支持 HTTP/2，某些老 LB（如 Nginx net/http: request canceled (Client.Timeout exceeded while awaiting headers)。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 除非你 100% 确认服务端全链路支持 HTTP/2（含 TLS 版本、ALPN 协商），否则别碰
ForceAttemptHTTP2 - 真正要优化吞吐，优先调好连接池 +
TLSClientConfig的GetClientCertificate（如需双向认证） - 用
curl -v --http2 https://your-api/验证服务端实际响应的协议版本，比代码里硬设更可靠
怎么验证连接真的被复用了
光看 QPS 上不去没用。得确认底层 TCP 连接没反复创建销毁。最直接的方式是抓包或看 Go runtime 指标，但开发期更实用的是打日志 + 观察连接生命周期。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 给
http.Transport加Trace（用httptrace.ClientTrace），监听GotConn和PutIdleConn事件，打印Conn.Reused字段 - 启动时加
GODEBUG=http2debug=2，看是否打出http2: Framer 0xc000…: read frame类日志（说明 HTTP/2 复用生效） - 线上环境用
lsof -i -n -p $(pidof your-app) | grep ESTABLISHED | wc -l对比压测前后连接数变化，稳定在几十以内才算健康
连接池配置不是一劳永逸的事——host 列表变、下游扩容缩容、网络中间件升级，都可能让原来合理的参数变成瓶颈。最常被忽略的其实是 Response.Body 忘记 Close()，这会让连接卡在 idle 状态直到超时，直接废掉整个池子的复用率。
