如何使用Golang实现HTTP客户端请求重试_Golang HTTP Client异常处理方法-Golang-PHP中文网

HTTP Client 默认不重试，必须手动实现；仅对301/302重定向且限GET/HEAD内部重试，网络层错误（如超时、DNS失败）需业务层封装指数退避重试，并注意Body可重放性。

如何使用golang实现http客户端请求重试_golang http client异常处理方法

HTTP Client 默认不重试，必须手动实现

Go 标准库的 http.Client 在遇到网络错误（如连接超时、DNS失败、TLS握手失败）时**不会自动重试**，哪怕只是临时性抖动。它只在极少数 HTTP 状态码（如 301/302 重定向）下内部重试，且仅限 GET/HEAD 方法。这意味着你调用 client.Do(req) 后拿到 err != nil，基本就是请求彻底失败了——除非你自己加逻辑。

常见错误现象包括：net/http: request canceled (Client.Timeout exceeded while awaiting headers)、dial tcp: i/o timeout、tls: handshake failure。这些都不是服务端返回的 5xx，而是客户端底层连接阶段失败，标准 client 不会重试。

重试必须封装在业务调用层，不能依赖 http.Client 自身
不要对非幂等请求（如 POST/PUT/DELETE）无条件重试，可能造成重复提交
重试间隔建议用指数退避（exponential backoff），避免雪崩式重试冲击下游

用 http.Client + context.WithTimeout 实现可控重试

最轻量的做法是复用原生 http.Client，每次重试都新建 *http.Request 并带上独立的 context.Context 控制单次超时。关键点在于：重试逻辑与请求构造分离，避免共享可变状态。

示例中使用固定 3 次重试、初始 100ms 间隔、最大 1s 上限：

func doWithRetry(client *http.Client, req *http.Request, maxRetries int) (*http.Response, error) {
    var resp *http.Response
    var err error
    baseDelay := 100 * time.Millisecond
<pre class="brush:php;toolbar:false;">for i := 0; i  time.Second {
            delay = time.Second
        }
        time.Sleep(delay)
    }
}
return resp, err

}

func isNetworkError(err error) bool { if urlErr, ok := err.(*url.Error); ok { return urlErr.Err != nil && ( strings.Contains(urlErr.Err.Error(), "timeout") || strings.Contains(urlErr.Err.Error(), "connection refused") || strings.Contains(urlErr.Err.Error(), "i/o timeout") || strings.Contains(urlErr.Err.Error(), "no such host") ) } return false }

用第三方库 backoff/v4 简化指数退避逻辑

手写退避容易出错（比如忘记限制最大延迟、误用 defer 导致 context 泄漏）。推荐直接用 github.com/cenkalti/backoff/v4，它提供标准化的重试策略和错误分类支持。

git-log-tracker

Git post-commit 钩子 + SQLite 提交索引工具。自动将每次提交的元数据（哈希值、作者、分支、仓库、主题）记录到本地 SQLite 数据库中，随后提供一个命令行接口（CLI），支持查询、列表展示、统计、删除和更新记录。触发场景：管理 Git 钩子、跨仓库查询提交历史、定位某次提交所属的仓库、查看提交统计信息、将提交记录写入本地索引。当用户提及“提交日志记录”、“提交索引”、“跨仓库查找提交”、“Git 钩子管理”，或希望以结构化方式查询其提交历史时（即使未明确指出该工具），请使

下载

注意两点：一是用 backoff.WithContext 包装操作，确保整体超时可控；二是通过 backoff.WithRetryableError 显式定义哪些错误允许重试，避免把 401 或 404 也重试了：

import "github.com/cenkalti/backoff/v4"
<p>func doWithBackoff(client <em>http.Client, req </em>http.Request) (*http.Response, error) {
bo := backoff.WithContext(
backoff.NewExponentialBackOff(),
req.Context(),
)</p><pre class="brush:php;toolbar:false;">var resp *http.Response
err := backoff.Retry(func() error {
    r, e := client.Do(req.Clone(req.Context()))
    if e != nil {
        if isNetworkError(e) {
            return e // 触发重试
        }
        return backoff.Permanent(e) // 终止重试
    }
    resp = r
    // 可选：对 5xx 响应也视为可重试
    if resp.StatusCode >= 500 && resp.StatusCode <p>}</p>

重试时别忽略 Request.Body 的可重放性

这是最容易踩的坑：如果原始 req.Body 是 bytes.Reader 或 strings.Reader，那可以反复读；但如果是 os.File、net.Conn 或已关闭的 io.ReadCloser，重试时再调用 req.Body.Read() 就会返回 io.EOF 或 panic。

解决方案只有两个：

在发起请求前，把 Body 内容完全读入内存（如 bytes.Buffer），再用 bytes.NewReader(buf.Bytes()) 构造新 Body —— 适合小数据（
把原始 Body 数据作为参数传入重试函数，在每次重试时重新构造 bytes.NewReader(payload) —— 更安全，但需业务层持有 payload

如果你用 json.Marshal 构造 POST body，那就天然可重放；但若直接传 os.Stdin 或临时文件句柄，重试必然失败。