beego 默认不设http超时导致请求卡死，因httplib复用http.defaultclient且timeout=0；须用settimeout(连接超时,读写超时)显式配置，并对5xx/网络错误谨慎重试。
Beego 本身不内置 HTTP 客户端超时与重试逻辑，必须手动配置底层 http.Client 或使用 httplib 封装层显式设置。
为什么默认请求可能卡死？
Beego 的 httplib（如 httplib.Get()、httplib.Post()）底层复用 Go 标准库 http.DefaultClient，而该客户端的 Timeout 默认为 0 —— 即无限等待。一旦下游服务无响应或网络中断，调用将永久阻塞 goroutine。
- 常见错误现象：
httplib.Get("http://slow-or-dead-api.com").Response()长时间无返回，CPU 正常但协程堆积 - 真实场景：调用第三方支付回调、短信网关、内部微服务接口时极易触发
- 关键点：Beego 不会自动给
httplib注入超时，你得自己加
如何用 httplib 设置 connect + read/write 超时？
httplib 提供了 SetTimeout() 方法，接收两个 time.Duration 参数：连接超时（connect timeout）和读写超时（read/write timeout）。这是最直接、Beego 原生支持的方式。
- 示例：
req := httplib.Get("https://api.example.com/data"); req.SetTimeout(5*time.Second, 10*time.Second); resp, err := req.Response() - 注意：第二个参数是整个响应体读取的上限，不是单次 read；若响应体大且流式传输，需确保它覆盖完整传输时间
- 不推荐只设一个超时值（如
SetTimeout(10*time.Second, 0)），read/write 为 0 会退化为无读超时
如何实现简单重试（非幂等操作要谨慎）？
Beego 没有重试封装，需自行基于 httplib 或标准 http.Client 实现。重点在于控制重试次数、间隔和错误类型过滤。
- 只对临时性错误重试：网络超时（
net.Error）、连接拒绝、HTTP 5xx（如502、503、504），跳过 4xx（如400、401、404） - 避免指数退避过度：生产环境建议固定间隔（如 200ms）+ 最多 2 次重试，防止雪崩
- 代码示意（伪逻辑）：
for i := 0; i - 特别注意：POST/PUT 等非幂等请求重试前，务必确认服务端是否支持 idempotency key，否则可能重复扣款、发单
何时该放弃 httplib，改用标准 http.Client？
当需要精细控制 Transport 层（如连接池、TLS 配置、代理、自定义 Dialer）或集成外部重试库（如 backoff）时，httplib 的封装反而成了障碍。
- 典型需求：
InsecureSkipVerify: true（测试环境）、MaxIdleConnsPerHost调优、HTTP/2 支持、带 context 取消的请求 - 做法：绕过
httplib，直接构造&http.Client{Transport: &http.Transport{...}}，再调用client.Do(req) - Beego 中仍可复用其日志、配置能力：从
beego.AppConfig.String("http_timeout")读取超时值，传入 client 构造
超时和重试不是“加了就完事”的开关，而是要结合下游服务 SLA、请求语义（是否幂等）、连接复用策略来权衡。最容易被忽略的是：在 Beego 的 Controller 方法里发起 HTTP 请求时，没把超时值跟当前 this.Ctx.Input.Context 的 deadline 关联，导致即使上层已超时，子请求仍在跑。这点必须手工透传 context 或统一用带 cancel 的 client。
