Go HTTP重试需可控退避、限流与context超时控制：设总超时、每次派生带timeout的ctx、指数退避加随机抖动、信号量限并发、异步提交+回调解耦。
优化 Go 的 HTTP 请求重试逻辑，关键不在“多试几次”，而在于可控、可退避、不压垮服务端也不拖垮自己。异步 + 限流不是锦上添花，而是高并发场景下的安全底线。
用 context 控制超时与取消，避免 Goroutine 泄漏
每次重试都该绑定独立的 context，尤其要设 timeout 或 deadline。别让失败请求无限挂起，更别让重试堆积导致 Goroutine 爆炸。
- 为整个重试流程设总超时（如 10s），而非单次请求超时叠加
- 每次重试前用
context.WithTimeout(parentCtx, singleReqTimeout)派生新 ctx - 一旦 context Done，立即终止当前尝试并返回错误，不进下一次重试
指数退避 + 随机抖动，防雪崩更防重试共振
固定间隔重试会放大下游压力，所有客户端在同一时刻重试，等于主动发起 DDOS。退避必须带 jitter（随机偏移）。
- 基础退避：2ⁿ × base（如 base=100ms，第1次等 100ms，第2次等 200ms…）
- 加抖动：乘以 [0.5, 1.5) 区间的随机因子，避免重试时间对齐
- 限制最大退避时长（如不超过 2s），防止等待过久影响业务 SLA
用 semaphore 或 worker pool 限流，保护本地资源
异步重试 ≠ 放开并发。没有节制的 goroutine 启动，会快速耗尽内存和文件描述符。推荐用轻量信号量（如 golang.org/x/sync/semaphore）或固定 worker 池。
立即学习“go语言免费学习笔记（深入）”；
- 全局设置最大并发重试数（如 50），超出则阻塞或快速失败
- 每个重试任务获取信号量后才执行，完成后释放
- 避免在 HTTP 客户端层（如 http.Transport.MaxIdleConnsPerHost）和业务重试层重复限流，二者职责不同：前者管连接复用，后者管任务调度
异步提交 + 结果回调，解耦重试与业务主流程
主逻辑不该卡在重试上。把重试任务丢进队列，由后台 worker 处理，成功/失败通过 channel 或回调通知。
- 定义重试任务结构体：含 URL、body、重试次数、退避参数、success/fail 回调函数
- 用无缓冲或带缓存的 channel 接收任务，worker 从 channel 拉取执行
- 回调里处理业务侧日志、指标上报、降级逻辑（如写 DB 失败则发消息队列补偿）
基本上就这些。不复杂但容易忽略——真正健壮的重试，是安静的、有边界的、能自愈的。
