Go 的 http.DefaultClient 默认复用连接，但因 MaxIdleConns 和 MaxIdleConnsPerHost 默认值偏低（100），高并发下易成瓶颈；需自定义 Transport 并合理配置参数，且务必调用 resp.Body.Close() 释放连接。
Go 的 http.DefaultClient 默认不复用连接？
不是“不复用”，而是默认复用，但复用行为受底层 http.Transport 控制；http.DefaultClient 的 Transport 实例默认启用了连接复用，但关键参数（如 MaxIdleConns、MaxIdleConnsPerHost）设得极低（Go 1.12+ 后是 100 和 100），看似够用，实际高并发场景下极易成为瓶颈。
常见现象：压测时出现大量 dial tcp: lookup xxx: no such host 或 context deadline exceeded，同时 netstat -an | grep :443 | wc -l 显示 ESTABLISHED 连接数卡在几十，远低于预期——这往往不是 DNS 或服务端问题，而是客户端连接池提前耗尽或过早关闭空闲连接。
-
MaxIdleConns控制整个客户端可保持的空闲连接总数，设为0表示不限（不推荐），设太小（如10）会导致多 Host 场景下争抢严重 -
MaxIdleConnsPerHost是更关键的参数，它限制每个域名（含端口、协议）最多缓存多少空闲连接；若调用多个子域名（如api-v1.example.com、api-v2.example.com），它们被视作不同 Host，各自独立计数 -
IdleConnTimeout默认30s，太短会让刚建好的连接很快被关，反复握手；太长则占用 fd 资源；建议按后端 Keep-Alive 设置略大一点（如后端设60s，这里设75s）
如何安全地自定义 http.Transport 并复用？
不要每次请求都 new 一个 http.Client，也不要直接修改 http.DefaultClient.Transport（全局共享，易被其他库意外覆盖）。正确做法是构建专用 client 实例，并确保 Transport 单例复用。
实操建议：
- 把
&http.Transport{...}提取为包级变量或依赖注入的单例，避免重复初始化 TLS 配置和连接池结构体 - 显式设置
ForceAttemptHTTP2: true（Go 1.8+ 默认开启，但显式写出来更清晰） - 如果需要代理或自定义 TLS，务必在 Transport 初始化时一并配置，否则后续修改会失效（Transport 启动后部分字段只读）
- 示例关键片段：
var customClient = &http.Client{ Transport: &http.Transport{ MaxIdleConns: 200, MaxIdleConnsPerHost: 200, IdleConnTimeout: 75 * time.Second, TLSHandshakeTimeout: 5 * time.Second, }, }
http.Client 的 Timeout 和 Transport 层超时有何区别？
http.Client.Timeout 是**整个请求生命周期**的兜底超时（从 Do() 开始到响应 body 读完），它会自动为底层 Transport 的各阶段（Dial、TLS handshake、response header、body read）设置子超时；而 Transport 中的 DialContextTimeout、TLSHandshakeTimeout 等是更细粒度的控制，仅作用于对应阶段。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
容易踩的坑：
- 只设了
Client.Timeout，但后端偶尔 TLS 握手慢（如证书链校验复杂），导致请求在握手阶段就超时，而你误以为是网络或路由问题 - 设了很短的
TLSHandshakeTimeout（如1s），但没同步调大Client.Timeout，结果 Client 层超时先触发，掩盖了真实瓶颈 - 使用
context.WithTimeout传入Do()时，它会覆盖Client.Timeout，此时 Transport 子超时仍生效，但整体以 context 为准
连接池调优后为何还出现 too many open files？
根本原因不是连接池开太多，而是文件描述符（fd）耗尽——每个 TCP 连接占 1 个 fd，加上日志、监控、其他 goroutine 打开的文件，很容易突破系统默认 limit（通常是 1024）。
排查与解决路径：
- 用
lsof -p $(pidof yourapp) | wc -l查当前进程 fd 数，确认是否真超限 - 检查
MaxIdleConns和MaxIdleConnsPerHost是否设得远高于实际并发需求（比如设了1000，但峰值 QPS 只有 50，且平均响应时间200ms，理论最大活跃连接 ≈50 × 0.2 = 10） - 确认没有泄漏：每次
resp.Body是否都调用了Close()？漏关会导致连接无法归还池中，持续占用 fd - 终极手段：启动前调用
syscall.Setrlimit(syscall.RLIMIT_NOFILE, &rLimit)（需 importsyscall），但必须配合运维调整系统级 limit，不能只靠代码硬扛
真正难调的点不在参数值本身，而在理解你的流量模式：是短连接突发型，还是长连接保活型；后端是否支持 HTTP/2；DNS 解析是否稳定。这些决定了 IdleConnTimeout 和 MaxIdleConnsPerHost 的合理量级，而不是套用网上流传的“200/200”万能公式。
