调用第三方 api 时构建具备重试机制的 http 客户端可提升稳定性。1. 控制重试次数，一般设为 2~3 次；2. 设置合理间隔时间，建议使用指数退避策略；3. 区分可重试与不可重试错误，如网络超时、连接失败和 5xx 错误可重试，4xx 和 tls 握手失败通常不重试；4. 使用自定义 roundtripper 实现重试逻辑，在每次请求失败后判断错误类型并决定是否重试；5. 结合 context.context 控制超时，记录日志以便排查问题；6. 封装成通用组件便于复用，提供默认配置同时支持自定义参数。通过这些策略，能有效增强程序的健壮性。
调用第三方 API 时出错是常态，特别是在网络不稳定、服务端偶发异常的情况下。Golang 中构建一个具备重试机制的 HTTP 客户端，能有效提升程序的健壮性和稳定性。重点在于控制重试次数、设置合理的间隔时间，并区分可重试与不可重试的错误。
了解哪些错误值得重试
不是所有错误都适合重试。比如：
-
网络超时（如
i/o timeout
）：可能是暂时性问题，可以尝试再次请求。 -
连接失败（如
connection refused
）：可能是目标服务短暂不可用，也适合重试。 -
5xx 错误（如
500 Internal Server Error
）：服务端出错，通常可以再试一次。 -
4xx 错误（如
400 Bad Request
,404 Not Found
）：客户端错误，无需重试。 - TLS 握手失败：可能是证书问题，不一定适合重试。
在实现中，需要根据这些错误类型来决定是否继续重试。例如通过检查
error类型或响应状态码。
立即学习“go语言免费学习笔记（深入）”；
使用 http.Client
自定义 RoundTripper 实现重试
Go 的标准库允许我们自定义
RoundTripper来拦截和处理请求。我们可以在这里加入重试逻辑。
一个简单的思路是：
- 发起请求
- 若出现可重试错误，等待一段时间后重试
- 达到最大重试次数后停止并返回错误
示例结构如下：
type RetryingRoundTripper struct {
base http.RoundTripper
retries int
waitTime time.Duration
}
func (rt *RetryingRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
var resp *http.Response
var err error
for i := 0; i <= rt.retries; i++ {
resp, err = rt.base.RoundTrip(req)
if err == nil {
// 请求成功
return resp, nil
}
// 判断是否属于可重试错误
if isRetryableError(err) {
time.Sleep(rt.waitTime)
continue
}
// 不可重试，直接返回错误
return nil, err
}
return nil, fmt.Errorf("request failed after %d retries", rt.retries)
}其中
isRetryableError()函数可以根据错误类型做判断，比如检查是否为超时或特定网络错误。
设置合适的重试策略
重试不是越多越好，策略设置要合理：
- 重试次数：一般设为 2~3 次即可。太多会增加延迟，太少可能无效。
- 间隔时间：建议使用指数退避（exponential backoff），比如 1s → 2s → 4s。
- 上下文取消：如果请求本身有 context 超时，重试不应超过该限制。
- 日志记录：每次重试都应记录日志，方便排查问题。
你可以结合
context.Context和
time.AfterFunc控制整个流程的时间边界。
封装成通用组件更便于复用
为了在多个项目中复用这个逻辑，可以封装成一个构造函数，提供默认参数，同时支持自定义配置。例如：
func NewRetryingClient(retries int, waitTime time.Duration) *http.Client {
return &http.Client{
Transport: &RetryingRoundTripper{
base: http.DefaultTransport,
retries: retries,
waitTime: waitTime,
},
Timeout: 10 * time.Second,
}
}这样在调用第三方 API 时，只需传入你配置好的 client 即可。
基本上就这些。写得简单点，就是一个带重试的 RoundTripper 加上一些策略判断。不复杂但容易忽略细节，比如错误判断、上下文控制、日志输出等，这些才是真正影响稳定性的关键点。
