直接在handler中使用http.DefaultClient调用第三方API是危险的，因其无默认超时，易导致goroutine挂死、服务夯住；必须封装独立service层，注入带上下文的*http.Client，动态控制超时，解析非2xx响应并分类错误，重试需指数退避。
直接在 handler 里用 http.DefaultClient 调用第三方 API 是危险的
它没有默认超时，一旦下游服务卡住或网络抖动，整个 Goroutine 就会挂死，Gin 的并发优势瞬间归零。你看到的接口响应延迟、504、甚至整个服务夯住，大概率就是这个原因。
必须把第三方调用从路由逻辑里剥离开，封装成独立 service 函数，并强制注入带上下文的 *http.Client 实例。
- 永远不用
http.DefaultClient—— 它不可控、不可测、无法取消 - 所有请求必须走
http.NewRequestWithContext(ctx, ...)，让请求生命周期与 Gin 的c.Request.Context()绑定 - 超时不能写死在 client 初始化里（比如
Timeout: 5 * time.Second），而应由具体业务决定；更推荐在req.WithContext()阶段动态控制 - 别在 handler 里手动
defer resp.Body.Close()—— 应该封装进 service 方法内部统一处理
ThirdPartyClient 结构体必须支持依赖注入和可测试性
硬编码 URL、Token 或 client 配置会导致：本地联调要改代码、测试时无法 mock、上线后没法按环境切换 endpoint。结构体设计要允许外部传入所有可变项。
示例中这个写法是错的：
func GetUser(userID string) (UserResp, error) {
// baseURL 写死，client 没法替换 → 测试只能真发请求
resp, _ := http.DefaultClient.Get("https://api.example.com/users/" + userID)
// ...
}正确做法是定义一个可配置、可注入的结构体：
type ThirdPartyClient struct {
baseURL string
token string
client *http.Client
}
<p>func NewThirdPartyClient(baseURL, token string, client <em>http.Client) ThirdPartyClient {
if client == nil {
client = &http.Client{Timeout: 8 </em> time.Second}
}
return ThirdPartyClient{baseURL: baseURL, token: token, client: client}
}</p><p>func (c ThirdPartyClient) GetUser(ctx context.Context, userID string) (UserResp, error) {
req, err := http.NewRequestWithContext(ctx, "GET", c.baseURL+"/users/"+userID, nil)
if err != nil {
return UserResp{}, err
}
req.Header.Set("Authorization", "Bearer "+c.token)
resp, err := c.client.Do(req)
if err != nil {
return UserResp{}, fmt.Errorf("http call failed: %w", err)
}
defer resp.Body.Close()
// 后续解析...
}非 2xx 响应不能直接转成 500 错误返回给前端
第三方 API 返回 429 Too Many Requests 或 401 Unauthorized，你却 c.JSON(500, gin.H{"error": "第三方调用失败"})，前端完全无法区分是自己 Token 过期，还是对方限流了——这会让问题定位变成盲猜。
必须读取并解析第三方的响应 body，再映射为内部错误码：
- 先检查
resp.StatusCode，不是 2xx 就别急着解 JSON - 用
ioutil.ReadAll(resp.Body)（Go 1.16+ 推荐io.ReadAll）读取原始 body，避免后续重复读取失败 - 对常见错误码做分类：比如
429→ 自定义ErrRateLimited，401/403→ErrAuthFailed - 错误信息里保留原始 status code 和第三方返回的
error字段（如{"error": "invalid_grant"}），方便排查
重试逻辑必须带指数退避和最大次数限制
简单写个 for i := 0; i 不仅浪费资源，还可能放大雪崩效应。下游已经慢了，你还每 100ms 重试一次，只会让它更慢。
推荐使用 github.com/cenkalti/backoff/v4 或手写基础版指数退避：
func (c ThirdPartyClient) DoWithRetry(ctx context.Context, req *http.Request, out interface{}) error {
var err error
for i := 0; i < 3; i++ {
select {
case <-ctx.Done():
return ctx.Err()
default:
}
resp, err := c.client.Do(req)
if err == nil && resp.StatusCode >= 200 && resp.StatusCode < 300 {
// 成功，解析 body
return json.NewDecoder(resp.Body).Decode(out)
}
// 失败则等待后重试
time.Sleep(time.Duration(1<<uint(i)) * time.Second) // 1s, 2s, 4s
if i == 2 {
break
}
// 重试前克隆 request（body 可能已关闭）
req = req.Clone(ctx)
}
return err
}注意：每次重试都要用 req.Clone(ctx)，否则 body 可能已被消费；且重试次数别超过 3 次，避免拖垮自身服务。
最易被忽略的一点：重试只适用于幂等操作（如 GET /users/{id}），对 POST 创建类请求，重试前必须确认下游是否支持幂等 key（如 X-Idempotency-Key），否则可能造成重复下单、重复扣款。
