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 更可靠。
关键点在于：重试不是“失败就重来”，而是“失败且满足条件才重试”。需要把「是否重试」的决策从重试框架里解耦出来。
func doHTTPRequestWithRetry(ctx context.Context, req *http.Request) (*http.Response, error) {
var resp *http.Response
var err error
<pre class="brush:php;toolbar:false;">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 <p>}</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill12097" title="GitHub Push 自动推送"><img
src="https://img.php.cn/upload/skill/000/000/081/179412308077155.jpg" alt="GitHub Push 自动推送" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill12097" title="GitHub Push 自动推送" class="overflowclass">GitHub Push 自动推送</a>
<p class="overflowclass">使用自动 SSH 和远程配置实现安全的 GitHub 推送自动化。适用于执行 `git push`、自动化推送或处理冲突等场景。</p>
</div>
<a rel="nofollow" href="/xiazai/skill12097" title="GitHub Push 自动推送" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
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，否则问题定位成本极高
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
