直接用http.Client调外部服务会出问题，因其不内置熔断、重试或并发控制；下游抖动时易导致重复压垮、goroutine卡死、超时堆积、错误误判重试。
为什么直接用 http.Client 调外部服务会出问题
因为 http.Client 本身不带熔断、重试或并发控制——它只管发请求、收响应。一旦下游抖动，你写的代码就容易：连续重试压垮对方、反复失败卡住 goroutine、超时没设导致协程堆积、错误类型不分全往里塞重试逻辑。
比如一个 GET /user 请求因网络丢包失败，你手动加个 for 循环重试 3 次，但第 2 次失败恰逢下游服务已彻底宕机，继续重试只会让问题扩散；又或者你没判断 os.IsNotExist 就对文件操作重试，结果权限错误也等 4 秒再报错，纯属浪费时间。
- 瞬时故障（如 TCP Reset）适合指数退避重试
- 持续故障（如 503 Service Unavailable）该立刻熔断，而不是等满 3 次才放弃
- 慢响应（如下游耗时 8s）必须配合
context.WithTimeout，否则拖垮整个调用链 - 并发突增（如秒杀场景批量查用户）得限制最大并发数，不然自己先 OOM
Icepick 怎么把熔断、重试、超时串成一条流水线
Icepick 的核心是把外部调用抽象成一个高阶函数：func() (T, error)，然后用策略层包装它。它不是替换 http.Client，而是在其之上叠加可靠性层。
典型流程是：先走熔断器检查状态 → 若闭合则执行带指数退避的重试 → 每次重试都套 context.WithTimeout → 失败计数触发熔断切换 → 半开状态下只放行一次试探请求。
立即学习“go语言免费学习笔记（深入）”；
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 熔断器用的是
sony/gobreaker，但Icepick隐藏了cb.Execute的样板代码，你只需传入业务函数 - 重试策略默认用
cenkalti/backoff/v4.NewExponentialBackOff()，起始间隔 100ms、最大 10s、最多 9 次，且自带 jitter - 每次重试都会新建
context.WithTimeout，避免前一次超时影响下一次 - 支持按错误类型过滤重试：比如只对
net.OpError或http.ErrHandlerTimeout重试，跳过json.UnmarshalTypeError
怎么写一个可复用的客户端封装
别在每个 handler 里重复写 backoff.Retry + gobreaker.NewCircuitBreaker —— 把它们组合进一个结构体，暴露干净的 Do 方法即可。
示例结构：
type ExternalClient struct {
httpClient *http.Client
breaker *gobreaker.CircuitBreaker
backoff backoff.BackOff
}
func (c *ExternalClient) Do(req *http.Request) (*http.Response, error) {
var resp *http.Response
err := c.breaker.Execute(func() (interface{}, error) {
// 每次重试都重置 backoff 计数器
c.backoff.Reset()
return backoff.Retry(func() error {
ctx, cancel := context.WithTimeout(req.Context(), 2*time.Second)
defer cancel()
req = req.Clone(ctx)
r, err := c.httpClient.Do(req)
if err != nil {
return err
}
if r.StatusCode >= 400 {
r.Body.Close()
return fmt.Errorf("http %d", r.StatusCode)
}
resp = r
return nil
}, c.backoff)
})
return resp, err
}
-
c.backoff.Reset()必须加，否则多次调用会复用已耗尽的计数器 - 错误判断放在重试内部，而不是外层——这样才能让
backoff.Retry知道该不该重试 -
req.Clone(ctx)是必须的，原req.Context()可能已被取消，不能复用 - HTTP 状态码错误（如 404、500）要显式返回 error，否则
backoff.Retry不会重试
哪些错误绝对不该重试
重试不是万能药。有些错误重试只会放大问题，甚至引发数据不一致。
-
os.IsPermission(err)、os.IsNotExist(err)：文件系统级永久错误，重试无意义 -
json.SyntaxError、encoding/xml.SyntaxError：响应体格式错误，说明上游数据异常，不是临时故障 -
sql.ErrNoRows：查不到数据是业务常态，不是失败 -
http.StatusUnauthorized、http.StatusForbidden：认证失败，重试不会变成功 -
context.Canceled、context.DeadlineExceeded：调用方已放弃，你还重试就违背语义
真正该重试的，只有那些明确表示“暂时不可用”的信号：网络超时、连接拒绝、HTTP 503、gRPC Code_Unavailable、数据库 sql.ErrConnDone。
