context.WithTimeout是Go中超时控制的唯一可靠入口，需传给支持context的函数（如http.Client.Do）才能中断底层I/O；仅靠time.After或goroutine+channel无法终止DNS解析、TCP连接等阻塞操作，且熔断必须用gobreaker等库实现并手动包装错误逻辑。
context.withtimeout 是 go 中控制外部 api 调用超时的唯一可靠方式，但仅靠它无法实现熔断；必须搭配 gobreaker 这类库，并手动处理错误分类与 fallback。
为什么不能只用 time.After 或 goroutine + channel 模拟超时
这类写法看似能“等 3 秒就放弃”，但根本无法中断底层阻塞操作——比如 DNS 解析卡住、TCP 连接 hang 在 SYN 包、TLS 握手没响应。这些阶段 context 尚未生效，而自建 channel 等待只是在上层空转，请求仍在后台运行，资源持续泄漏。
真正起作用的是：把 context.Context 传给支持它的函数（如 http.Client.Do），由标准库在 I/O 层主动取消。
http.Client 必须显式传入 context，且要配 Transport
常见错误是写了 ctx, cancel := context.WithTimeout(...)，却调用 client.Do(req) 而非 client.Do(req.WithContext(ctx))。更隐蔽的问题是：自定义 http.Client 时没设 Timeout 字段，也没配置 Transport.IdleConnTimeout 和 Transport.DialContext，导致连接建立阶段绕过 context 控制。
正确做法：
- 始终用
req.WithContext(ctx)构造带上下文的请求 - 初始化 client 时设置
Timeout: 5 * time.Second（覆盖整个请求生命周期） - 显式配置
Transport的IdleConnTimeout和ResponseHeaderTimeout，防止复用连接或 header 卡死
gobreaker 不是超时代理，得自己包装错误逻辑
gobreaker 默认只把返回 error != nil 的调用记为失败。但很多 HTTP 客户端 SDK（比如某些云厂商的 Go SDK）在超时后返回 nil, nil 或自定义错误类型，gobreaker 就不会统计——结果熔断器永远不触发。
必须手动包裹：
- 检查响应状态码是否为 2xx，非则返回 error
- 捕获
context.DeadlineExceeded并转为 error - 对 SDK 返回的空响应或特定错误码（如
"timeout"字符串）做显式 error 包装
否则 ReadyToTrip 函数看到的失败率永远是 0。
下游 SLA 不同，必须为每个依赖创建独立子 context
支付接口要求 800ms，用户服务可接受 2s，库存允许 3s——如果所有调用共用一个 context.WithTimeout(context.Background(), 2*time.Second)，支付请求会被拖慢，用户请求又可能因等待库存而超时级联失败。
正确做法是逐层派生子 context：
- 主请求进来时用
context.WithTimeout设总时限（如 3s） - 调用支付前：
payCtx, _ := context.WithTimeout(ctx, 800*time.Millisecond) - 调用用户前：
userCtx, _ := context.WithTimeout(ctx, 2*time.Second) - 每个子 context 都传给对应 client，且各自配熔断器实例
熔断器的 Timeout 字段（如 60 * time.Second）是 open 状态持续时间，和单次请求超时无关——混用同一数值会导致熔断器刚打开就立刻半开，失去保护意义。
实际最难的部分不是写代码，而是判断哪些错误该计入熔断、哪些该重试、哪些直接 fallback。比如 429（限流）和 503（服务不可用）语义完全不同，但都返回非 2xx；这需要结合业务日志、监控指标和下游文档来定策略，而不是靠通用库自动识别。
