仅靠 context.WithTimeout 不足以实现服务级容错，它只解决超时问题，无法处理重试、熔断、降级等关键链路，需结合 gobreaker 等库实现差异化错误处理与状态管理。
为什么直接用 context.WithTimeout 不足以实现服务级容错
超时只是容错的第一道防线，它只解决“等太久”的问题，但不处理“调用失败后怎么重试”“连续失败是否该熔断”“下游恢复了如何自动放行”这些关键链路。Golang 标准库本身不提供熔断、重试、降级等能力，必须组合第三方库或自建逻辑。
常见错误是把所有错误都塞进 context.WithTimeout，结果 HTTP 调用返回 503 Service Unavailable 或连接被拒绝（dial tcp: i/o timeout）时，程序仍盲目重试，加剧雪崩。
- 超时应与业务语义对齐：比如支付接口可设 800ms，而报表导出可设 30s
-
context.WithTimeout必须在发起调用前就传入 client 方法（如http.Client.Do(req.WithContext(ctx))），否则无效 - 仅靠超时无法区分临时性错误（网络抖动）和永久性错误（404、401），需配合错误类型判断做差异化处理
用 gobreaker 实现熔断器的最小可行配置
gobreaker 是目前最轻量且符合 Go 风格的熔断库，不需要依赖外部存储或协调服务，状态完全内存化，适合单体微服务实例内部使用。
关键不是“加熔断”，而是“什么时候打开、什么时候半开、什么时候关闭”。默认配置（20次失败触发、60秒窗口）在高 QPS 场景下容易误判，建议按实际流量调整：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 设置
ReadyToTrip函数，只对网络类错误（如*url.Error、net.OpError）计数，忽略业务错误（如400 Bad Request） -
OnStateChange回调里打日志或发指标（如 Prometheusbreaker_state{service="user"} 1），否则熔断静默发生，排查困难 - 避免在 HTTP handler 中直接 new 一个
gobreaker.CircuitBreaker，应全局复用同一实例，否则每个请求新建熔断器等于没用
cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "user-service-client",
MaxRequests: 3,
Interval: 60 * time.Second,
Timeout: 5 * time.Second,
ReadyToTrip: func(counts gobreaker.Counts) bool {
return counts.ConsecutiveFailures > 3
},
})
重试策略必须带退避 + 条件过滤，不能无脑 for i := 0; i
固定次数重试在真实微服务调用中风险极高：下游正在重启时，3 次密集重试可能压垮刚起来的服务；幂等性没保障时，重复支付、重复发消息就发生了。
真正可用的重试要同时满足三个条件：可退避、可中断、可过滤。
- 用
backoff.Retry（来自github.com/cenkalti/backoff/v4）替代手写 for 循环，支持指数退避、 jitter 和最大耗时限制 - 重试前检查错误是否值得重试：只重试
io.EOF、net.ErrClosed、context.DeadlineExceeded等临时错误，跳过json.UnmarshalTypeError这类客户端错误 - HTTP 场景下，必须确认请求方法是幂等的（
GET、PUT、DELETE），POST默认不重试，除非服务端明确支持幂等 key（如带X-Idempotency-Keyheader）
降级逻辑不能写死在主流程里，要用 func() interface{} 注入
硬编码降级（比如 “调用失败就返回空用户结构体”）会让代码难以测试、无法动态变更，且一旦降级逻辑出 bug，主流程也跟着挂。
推荐用函数值注入方式，把降级行为从核心路径解耦：
- 定义统一降级接口：
type FallbackFunc func(err error) (interface{}, error) - 在调用点显式传入，例如
callUserService(ctx, req, userFallback)，而非在函数内部 if-else 判断 - 降级函数本身应尽量轻量：查本地缓存、返回静态兜底数据、调用更稳定的备用服务；避免在降级里再发起一次远程调用
- 注意 panic 安全：降级函数执行时若 panic，需 recover 并记录日志，否则整个调用链崩溃
复杂点在于熔断、重试、超时、降级四者嵌套顺序——通常应是：先设超时 → 再套重试 → 外层包熔断 → 最后 fallback。顺序颠倒会导致降级被反复触发，或熔断器统计失真。
