go并发超时、重试与熔断需分层控制：超时用context.withtimeout逐层透传并注入底层操作；重试需分类错误、指数退避+jitter、每次新建子context；熔断依赖gobreaker等库实现三态状态机，配合监控告警定位根因。
Go 语言处理并发请求下的超时、重试与熔断，不是堆砌几个库就能解决的事。核心在于分层控制：单次请求要可取消、可超时；多次尝试要有节奏、有边界；而当失败成为常态，就得果断切断，避免拖垮整条调用链。
超时必须从 context 入手，且逐层透传
超时控制唯一可靠的方式是 context.WithTimeout，但光创建 context 不够——必须把它真正传到底层操作中：
- HTTP 请求要用
req.WithContext(ctx)，不能只写ctx, cancel := context.WithTimeout(...)却没传进client.Do() - 数据库操作要用
QueryContext、ExecContext等支持 context 的方法 - 不同下游服务 SLA 不同（比如支付要求 800ms，用户服务允许 2s），应为每个调用单独设子 context，而不是整个流程共用一个 timeout
- 自定义 HTTP client 需显式设置
Timeout和Transport.IdleConnTimeout，否则 DNS 解析或连接建立阶段可能绕过 context 控制
重试不能盲目循环，得讲策略和判断
Go 没有内置重试原语，所有逻辑都得手动编排。关键不是“重试几次”，而是“什么时候重试、隔多久、重试什么”：
- 错误需分类：网络超时、5xx 服务端错误适合重试；4xx 客户端错误（如 400、404）通常不重试
- 推荐用指数退避（1s → 2s → 4s），比固定间隔更友好；再叠加 Jitter（±30% 随机抖动），防止大量请求在恢复瞬间集中冲击下游
- 每次重试前新建独立的
context.WithTimeout，避免上一次超时影响下一次 - 用
select同时监听ctx.Done()和结果 channel，确保 goroutine 不泄漏
熔断是故障状态管理，不是超时的加强版
超时只能让单次请求快失败，熔断解决的是“连续失败怎么办”。它靠统计+状态机实现，不能靠自己硬写：
- 用 gobreaker 这类成熟库，它内置 Closed / Open / Half-Open 三态、滑动窗口计数、半开试探等关键逻辑
-
ReadyToTrip函数决定何时熔断，例如：60 秒内失败率超 60%，或连续失败 ≥3 次 -
Timeout是熔断器保持 Open 的时长（比如 60s），不是单次请求超时时间，别和 context 超时混用同一数值 - Half-Open 状态下，只允许最多
MaxRequests次试探请求（如 5 次），成功后才恢复调用，不是放行全部流量
监控和日志必须跟上，否则就是黑盒
重试和熔断一旦启用，行为必须可观测：
- 每次重试记录：重试次数、当前间隔、错误类型、最终是否成功
- 熔断器状态变化（如 Closed → Open）要打日志，并触发告警
- 用 Prometheus 暴露指标：重试率、熔断触发次数、各状态持续时长，接入 Grafana 做趋势分析
- 高重试率或频繁熔断不是机制生效了，而是上游或依赖出了问题，得倒查根因
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
