Go 的 retry.Do 不能直接用于 HTTP 客户端，因其默认不检查 HTTP 状态码，需手动包装 Do 方法并针对 429、5xx 等状态主动返回错误，同时注意 body 关闭、超时嵌套、熔断器错误分类及降级无依赖等细节。
Go 的 retry.Do 为什么不能直接用在 HTTP 客户端上
因为 retry.Do（来自 github.com/avast/retry-go 或类似库）默认不感知 HTTP 状态码，它只捕获 panic 和 error，而像 429 Too Many Requests、503 Service Unavailable 这类响应会正常返回 *http.Response，不会触发重试。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须手动包装
http.Client.Do，检查resp.StatusCode，对特定码（如 429、500–599）主动返回错误，例如：return fmt.Errorf("unexpected status: %d", resp.StatusCode) - 避免在
retry.Do内部调用resp.Body.Close()—— 重试时 body 可能已读完或未读，应由外层统一关闭 - 别把
context.WithTimeout套在retry.Do外层就以为万事大吉；要确保每次重试子请求也带独立短超时（比如 2s），否则一次卡死会拖垮整个重试周期
用 gobreaker 实现降级时，cb.Execute 的 error 类型必须严格匹配
gobreaker 的熔断器只对 cb.Execute 返回的 error 做失败计数，但它**不区分 error 类型** —— 即使是 errors.New("not found") 这种业务正常 error，也会被计入失败率。结果就是：服务明明健康，熔断器却误开。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义一个可识别的“真实失败”错误类型，比如
var ErrTransient = errors.New("transient failure") - 在调用下游前做预检（如 DNS 解析失败、连接 refused），遇到这类问题才 wrap 成
ErrTransient；HTTP 404、400 等明确语义的响应，直接返回原 error，不进熔断统计 - 设置
gobreaker.Settings{ReadyToTrip: func(counts gobreaker.Counts) bool { return counts.ConsecutiveFailures > 5 }}，避免默认的 50% 失败率策略在低流量下过早触发
重试 + 熔断 + 降级三者嵌套时，调用顺序决定行为边界
典型错误写法是把 retry.Do 套在 cb.Execute 外面：这样一旦熔断开启，每次重试都会立刻失败，反而放大错误日志和延迟。正确顺序是「熔断最外层 → 重试在内层 → 降级兜底在最里层」。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 结构应为：
cb.Execute(func() (interface{}, error) { return retry.Do(..., retry.Context(ctx), ...) }) - 降级函数（fallback）不要包含任何外部依赖 —— 它只能返回缓存值、默认结构体或本地计算结果；例如：
return User{Name: "guest"}, nil，而不是再去查 Redis - 如果降级逻辑本身可能 panic（比如空指针解引用），
gobreaker不会捕获，需在外层加defer/recover，否则整个 goroutine crash
Go 微服务中时间控制容易被忽略的两个硬伤
一是重试间隔用 time.Sleep 硬等，导致协程阻塞且无法响应 cancel；二是熔断器恢复期（sleepWindow）设为固定值，没考虑下游恢复的实际节奏。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有重试 delay 必须走
time.AfterFunc或基于timer.Reset()的非阻塞方式，且每次 delay 前检查ctx.Err() != nil -
gobreaker的SleepWindow建议设为动态值：首次熔断用 30s，若连续三次恢复后又失败，下次升为 60s，上限封顶到 5m —— 这需要自己封装状态机，不能只靠静态配置 - HTTP 客户端的
Timeout、重试的Context超时、熔断器的SleepWindow三者数值要有梯度（例如 2s
真正难的不是堆砌重试或加个熔断器，而是让它们在并发、超时、错误语义、上下文取消之间不互相撕扯。每个环节的 error 是否该传播、timeout 是否该继承、fallback 是否真无副作用——这些判断点藏在每行调用背后，没法靠模板生成。
