beego中默认HTTP客户端不启用连接池，因http.DefaultTransport的MaxIdleConns和MaxIdleConnsPerHost默认为0，导致每次请求新建TCP连接、空闲连接几乎不复用，高并发时引发TIME_WAIT堆积和“too many open files”错误；须显式构建并全局复用配置了MaxIdleConns、MaxIdleConnsPerHost、IdleConnTimeout及Client.Timeout的自定义http.Client，并确保每次调用后close resp.Body。
beego中默认HTTP客户端不启用连接池
beego自身不封装或替换http.DefaultClient，所有通过http.Get、http.Post等直接调用的请求，底层都走http.DefaultTransport。而它的MaxIdleConns和MaxIdleConnsPerHost默认为0，IdleConnTimeout为30秒——这意味着：每次请求都会新建TCP连接，且空闲连接几乎不复用。
后果很直接：高并发时出现大量TIME_WAIT连接，本地端口耗尽，报错类似dial tcp: lookup xxx: no such host或too many open files。
解决方式不是改beego配置，而是**显式构造带连接池的*http.Client并复用它**。
如何安全复用自定义http.Client实例
不能在每个请求里临时创建http.Client，也不能全局单例后随意修改Transport字段（http.Transport非线程安全）。正确做法是：
- 在
init()或应用启动阶段，一次性构建一个*http.Client，其Transport参数固定 -
Transport必须设置MaxIdleConns、MaxIdleConnsPerHost、IdleConnTimeout三项（仅设其中一两个效果有限） - 避免设置
ResponseHeaderTimeout或TLSHandshakeTimeout过短，否则可能中断正常长响应
示例：
var httpClient = &http.Client{
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 90 * time.Second,
// 可选：防止DNS缓存过久
// ForceAttemptHTTP2: true,
},
Timeout: 10 * time.Second,
}
beego Controller里调用自定义客户端的典型写法
在Controller方法中，直接使用预定义的httpClient发起请求即可。注意两点：
- 不要在
Prepare()或Init()里覆盖c.Ctx.Request或试图劫持原始http.DefaultClient - 若需携带beego session或cookie，需手动从
c.Ctx.Request提取并注入到新http.Request中（httpClient不自动继承上下文） - 错误处理要覆盖
url.Error、context.DeadlineExceeded等常见类型，不能只判err != nil
简单调用示意：
resp, err := httpClient.Get("https://api.example.com/data")
if err != nil {
c.Data["json"] = map[string]interface{}{"error": "request failed"}
c.ServeJSON()
return
}
defer resp.Body.Close()
容易被忽略的超时组合与连接泄漏风险
很多人只设Client.Timeout，却忽略Transport内部的超时参数，导致连接卡住不释放：
-
Client.Timeout控制整个请求生命周期（含DNS、连接、TLS握手、发送、接收），但一旦开始读body，就不再生效 -
Transport.ResponseHeaderTimeout控制从连接建立到收到响应头的时间，缺失会导致header卡死 -
Transport.ExpectContinueTimeout影响100-continue流程，一般可不设 - 最关键的是：
resp.Body必须Close()，否则底层连接永远不会归还给池——哪怕用了连接池，漏关Body也会导致连接泄漏
真正稳定的配置至少包含：Client.Timeout + Transport.IdleConnTimeout + 显式resp.Body.Close()。
