Go 中超时控制唯一可靠入口是 context.WithTimeout，需与支持 context 的函数配合使用；熔断必须用 gobreaker 等库实现，不可仅靠超时；HTTP 调用链须逐层传递不同粒度子 context，且需 fallback 保障可用性。Go 的 context.WithTimeout 是超时控制的唯一可靠入口超时不是靠 time.Sleep 或手动 goroutine + channel 等待来模拟的——那样无法中断正在执行的 I/O 或阻塞调用。真正起作用的是 context.Context 与支持 context 的函数（如 http.Client.Do、sql.DB.QueryContext）配合。常见错误是只对发起请求前加 timeout，但没传给底层 client：写了 ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)，却调用 client.Do(req)（没用 client.Do(req.WithContext(ctx))）自定义 HTTP client 时没设置 Timeout 字段，又没配 Transport 的 IdleConnTimeout，导致 DNS 解析或连接建立阶段卡死，绕过 context 控制在非标准库 HTTP 客户端（比如某些 SDK）里，误以为传了 ctx 就万事大吉，实际该 SDK 根本不读取 context熔断不能只靠超时，得用 gobreaker 这类库做状态跟踪超时只是触发条件之一；熔断需要统计失败率、维持状态（closed/half-open/open）、有重试退避逻辑。标准库没有熔断器，硬写容易漏掉半开状态探测、滑动窗口计数等关键细节。用 gobreaker 是目前最稳妥的选择，它默认使用指数退避 + 滑动时间窗口（默认 60 秒），且能和 context 自然结合：立即学习“go语言免费学习笔记（深入）”；cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{ Name: "payment-api", MaxRequests: 5, Timeout: 60 * time.Second, ReadyToTrip: func(counts gobreaker.Counts) bool { return counts.TotalFailures > 3 && float64(counts.TotalFailures)/float64(counts.TotalRequests) > 0.6 },})MaxRequests 在 half-open 状态下只允许最多 N 次试探请求，不是并发限制Timeout 是熔断器保持 open 状态的时间，不是单次请求超时——别和 context.WithTimeout 混用成同一数值如果底层函数不返回 error（比如返回 nil, nil 表示空响应），gobreaker 不会当失败，需手动包装逻辑HTTP 调用链中，超时必须逐层向下传递，且每层设不同粒度一个典型服务可能同时调用支付、用户、库存三个下游，它们的 SLA 不同：支付要求 800ms 内返回，用户可放宽到 2s，库存允许 3s。统一用一个 context.WithTimeout 会拖垮整体可用性。 ARTi.PiCS ARTi.PiCS是一款由AI驱动的虚拟头像生产器，可以生成200多个不同风格的酷炫虚拟头像