go模块不提供自动重试能力,需业务层显式编排;http.client.do不重试,须手动实现含context、错误分类、退避策略和重试边界的逻辑。

Go 模块本身不提供“自动降级重试”能力——这是业务逻辑层必须显式编排的容错行为,不是 import 一个包就能生效的魔法。真正起作用的是你如何组合 context、错误分类、退避策略和重试边界。
为什么 net/http.DefaultClient 不会自动重试
标准库的 http.Client 设计上就是“一次请求,一次响应”,它不检查状态码、不判断错误类型、不 sleep、不重试。哪怕遇到 503 Service Unavailable 或 net.OpError,它也只会原样返回错误。你以为的“失败重试”,其实是你在调用它之前或之后手动加的循环逻辑。
-
http.Client.Do返回后,连接可能已关闭(io.EOF),但 client 本身仍可复用;重试时必须新建*http.Request,不能复用旧 request 的 body(尤其 POST) - 若用
http.Transport配置了MaxIdleConnsPerHost,重试请求仍可能复用底层连接,但超时/断连错误不会触发自动重连 - 直接包装
Do方法容易漏掉重试前的 request 重建(比如签名、token、time.Now() 时间戳),导致第二次请求被后端拒绝
哪些错误该重试,哪些必须立刻放弃
盲目重试只会放大问题。关键不是“有没有 err”,而是 errors.Is 或 errors.As 能否匹配到临时性信号。
初始化并管理阿里云SDK Go 客户端,涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 可重试:
context.DeadlineExceeded、context.Canceled(仅当 cancel 是主动触发而非超时)、*net.OpError且.Op == "dial" || .Op == "read" || .Op == "write"、HTTP 状态码502/503/504/429 - 不可重试:
sql.ErrNoRows、json.SyntaxError、http.StatusNotFound(404)、http.StatusUnauthorized(401)、url.Error中Err是*url.Error(DNS 解析失败) - 特别注意:
http.ErrUseLastResponse表示重定向循环,重试会死循环;errors.Is(err, http.ErrHandlerTimeout)是服务端 handler 超时,客户端不该重试
用 backoff.Retry 时最容易漏掉的三件事
第三方库帮你省了退避计算,但没帮你做决策。很多项目跑着跑着就卡死或重试失控,往往栽在这三点。
- 没传带 timeout 的
context.Context:只传context.Background(),一旦最后一次重试的Do卡住(如对端不回包),整个 goroutine 永久阻塞 - 忘记设
req.Retryable = false:POST/PUT 请求默认true,但多数后端不幂等;重试前必须显式关掉,否则可能扣两次款 - 在
CheckRetry函数里只看 status code,却忽略req.Retryable字段:这个字段是开关,不检查它,自定义逻辑形同虚设
降级不是“重试失败后随便 return 个默认值”
真正的降级是带条件的 fallback:它依赖上游重试逻辑的明确退出信号,而不是靠 recover 或 panic 捕获。
- 降级入口必须和重试出口对齐:只有当
backoff.Retry返回非backoff.Permanent错误(即已穷尽所有重试)时,才执行降级;若中途因 context 被 cancel 退出,应传播 cancel,而非降级 - 降级逻辑自身不能引入新外部依赖:比如降级去查 Redis,结果 Redis 也挂了,那就真没路了;优先用本地缓存、静态配置或空结构体
- 别在重试循环里写
if err != nil { return fallback() }:这会让降级和重试耦合,无法统计真实失败率;应让重试函数返回明确 error 类型(如ErrRetryExhausted),再由外层 switch 判断
最易被忽略的点:抖动(jitter)不是锦上添花,而是生产环境的刚需。没有随机偏移的指数退避,在集群规模上来后,所有实例会在同一秒重试,瞬间压垮下游——这不是理论风险,是已经踩过的坑。
golang免费学习笔记(深入):立即使用
在学习笔记中,你将探索golang的核心概念和高级技巧!










