Go标准库net/http默认不重试，重试需手动实现；gRPC客户端支持声明式重试但需满足三条件；重试必须考虑幂等性、退避策略、上下文超时及系统容量约束。
Go 标准库 net/http 默认不重试，必须手动实现
HTTP 客户端发起请求后，只要底层连接建立成功、收到响应（哪怕是 500 或 408），http.DefaultClient 就会直接返回，不会自动重试。这是设计使然——重试逻辑涉及幂等性判断、退避策略、上下文超时传递等业务语义，标准库不越界处理。
常见错误是以为设置 http.Client.Timeout 或用 context.WithTimeout 就能触发重试，其实那只控制单次请求生命周期，和重试完全无关。
- 所有重试必须包裹在自定义函数或中间件中，例如封装为
DoWithRetry(req *http.Request, opts ...RetryOption) (*http.Response, error) - 务必检查响应状态码是否可重试：
502、503、504通常可重试；400、401、403、404一般不可重试 - 注意请求体（
req.Body）是否可重复读：若用bytes.NewReader或strings.NewReader构造，可安全重用；若来自文件或网络流，则需提前缓存
使用 backoff.Retry + 自定义判定函数最稳妥
第三方库 github.com/cenkalti/backoff/v4 提供了成熟的退避策略（指数退避、抖动等），配合闭包封装判定逻辑，比手写 for-loop 更可靠。
关键点在于：重试不是“失败就重来”，而是“失败且满足条件才重试”。需要把「是否重试」的决策从重试框架里解耦出来。
立即学习“go语言免费学习笔记（深入）”；
func doHTTPRequestWithRetry(ctx context.Context, req *http.Request) (*http.Response, error) {
var resp *http.Response
var err error
operation := func() error {
resp, err = http.DefaultClient.Do(req.WithContext(ctx))
if err != nil {
// 连接层错误（如 DNS 失败、拒绝连接）可重试
if netErr, ok := err.(net.Error); ok && netErr.Temporary() {
return backoff.Permanent(err) // 不重试的错误要显式标记
}
return err // 其他连接错误默认重试
}
// 响应已收到，检查状态码
if resp.StatusCode >= 500 && resp.StatusCode <= 599 {
return errors.New("server error, retryable")
}
if resp.StatusCode == 408 || resp.StatusCode == 429 {
return errors.New("request timeout or rate limited, retryable")
}
// 其他状态码（如 2xx、3xx、4xx）不重试
return backoff.Permanent(nil)
}
// 指数退避，最多 3 次，初始间隔 100ms，带抖动
b := backoff.NewExponentialBackOff()
b.MaxElapsedTime = 2 * time.Second
b.InitialInterval = 100 * time.Millisecond
err = backoff.Retry(operation, backoff.WithContext(b, ctx))
return resp, err}
gRPC 客户端重试需启用内置策略并配置服务端支持
gRPC Go 客户端（google.golang.org/grpc v1.29+）支持声明式重试，但必须同时满足三个条件：
- 客户端初始化时启用
grpc.WithDisableHealthCheck()（非必需，但健康检查干扰重试时建议关） - 调用时传入
grpc.CallOption，例如grpc_retry.WithMax(3) - 服务端必须返回可重试的状态码（
codes.Unavailable、codes.ResourceExhausted、codes.Aborted等），且不能在响应 header 中设置grpc-encoding: identity冲突
注意：gRPC 重试默认只对「无请求体的 unary 调用」安全，流式调用（stream）不支持自动重试，必须自行实现断点续传逻辑。
重试边界必须明确，避免雪崩和死循环
微服务场景下，上游重试可能放大下游压力。比如 A 调用 B，B 调用 C，若 A 和 B 都开启重试，C 的负载可能变成原始请求的 9 倍（3×3）。
实际部署中容易被忽略的是：重试必须受全局熔断器或限流器约束，不能脱离系统容量独立运行。
- 每个重试操作必须绑定一个独立的
context.Context，且该 context 的 deadline 应短于上游整体超时（例如上游给 5s，重试总耗时上限设为 3s） - 禁止在 HTTP handler 中对下游调用无限制重试；应将重试次数、最大延迟、错误白名单作为配置项注入，而非硬编码
- 日志中必须记录重试次数与最终结果，例如
level=warn msg="retry attempt 3 failed" status=503，否则问题定位成本极高
