go无原生装饰器，需用函数值和闭包模拟；服务端用包装http.handler实现请求拦截与重试，须避免body多次读取，仅对get/head重试；客户端侧应自定义http.roundtripper实现指数退避重试。
Go 里没有原生装饰器，得靠函数值和闭包模拟
Go 语言本身不支持 Python 那种 @decorator 语法，所谓“装饰器模式”在 Go 里本质是把 http.Handler 包一层函数，返回新的 http.Handler。核心就两点：接收原 handler、返回新 handler，在中间插入重试逻辑。
常见错误是直接在 ServeHTTP 里对整个请求重试——这会导致 body 被多次读取（req.Body 是 io.ReadCloser，读完就 EOF），后续重试会拿不到数据。
- 必须在重试前用
req.Body构造可重放的副本，比如用bytes.NewReader+io.ReadAll - 只对特定 HTTP 方法重试：通常只重试
GET和HEAD，POST/PUT默认不重试（除非业务明确允许幂等） - 别在装饰器里做耗时操作（如 sleep），要用
time.Sleep但得控制总超时，避免阻塞整个 handler
用 http.RoundTripper 实现客户端侧自动重试更合理
服务端 handler 装饰器适合拦截入站请求；但“HTTP 请求的自动重试”真正高频场景其实是 Go 程序作为客户端发请求（比如调第三方 API）。这时候该换思路：重写 http.Transport 的 RoundTrip 方法，而不是包装 http.Handler。
错误做法是每次调 http.DefaultClient.Do 前手动写 for 循环重试——分散、难统一、漏掉 timeout / backoff 控制。
立即学习“go语言免费学习笔记（深入）”；
- 自定义
RoundTripper实现，把重试逻辑收口到一次RoundTrip调用里 - 用指数退避（
time.Sleep(1 ）避免雪崩，别用固定间隔 - 注意重试时要 clone
*http.Request：原 request 的Body不能复用，得重新bytes.NewReader(bodyBytes) - 某些错误类型不该重试，比如
url.Error中的"EOF"或"connection refused"可重试，但400 Bad Request绝对不重试
retryablehttp 库能省事，但默认配置有坑
直接用 github.com/hashicorp/go-retryablehttp 是最快路径，但它默认开启对所有状态码重试（包括 4xx），线上出过问题。
典型现象：上游返回 401 Unauthorized，客户端反复重试 5 次，日志刷屏，还可能触发对方风控。
- 必须显式设置
CheckRetry：只对5xx和连接类错误（net.ErrClosed、context.DeadlineExceeded）重试 -
RetryMax别设太大（3–4 次足够），配合RetryWaitMin/RetryWaitMax控制退避范围 - 它内部用
http.Client，记得传入你自己的Timeout和Transport，否则默认 30s 超时可能掩盖真实问题 - 如果用了
SetDoNotParseResponse(true)，重试时 response body 不会自动关闭，得自己 deferresp.Body.Close()
重试不是万能药，超时和熔断必须配套
只加重试不控超时，等于把单次失败放大成多次失败。比如下游响应慢（2s），你设了 3 次重试 + 固定 1s 间隔，总耗时可能飙到 6s 以上，拖垮调用方。
容易被忽略的是：重试放大了并发压力。一个慢请求触发 3 次重试，相当于并发量 ×3，可能压垮下游或触发限流。
- 必须设全局上下文超时：
ctx, cancel := context.WithTimeout(parentCtx, 3*time.Second)，并在每次Do时传入 - 对关键依赖加熔断（如
gobreaker），连续失败 N 次后直接短路，跳过重试环节 - 记录重试次数到 metric（如 Prometheus counter），突然上涨说明下游不稳定或重试策略不合理
- 日志里打上
attempt=1/2/3和error="xxx"，别只记最终结果，否则查问题时看不到中间态
重试逻辑看着简单，但 body 复用、错误分类、超时嵌套、熔断联动这几处，少处理一个就会在线上变成定时炸弹。
