Go 无内置重试+幂等机制，需手动组合http.Client、重试逻辑与Idempotency-Key头；盲目重试POST/PUT易致重复扣款，因Body不可复用、未区分可重试状态码、缺乏唯一幂等标识。
Go 里没有内置的“自动重试 + 幂等”接口调用机制，必须手动组合 net/http、重试逻辑和幂等控制（比如 Idempotency-Key 头或服务端 token），否则重试大概率引发重复扣款、重复下单这类严重副作用。
为什么直接用 http.Client 重试会出问题
Go 标准库的 http.Client 默认不重试任何请求；即使你手动循环调用 Do()，也会忽略几个关键事实：
- HTTP 方法语义没被尊重：对
POST/PUT等非幂等方法盲目重试，等于默认允许重复提交 - 请求体（
Body）通常是一次性可读的io.ReadCloser，第二次重试时已 EOF，导致空请求体或 panic - 没有统一位置注入
Idempotency-Key或X-Request-ID，服务端无法识别这是重试还是新请求 - 超时、连接中断、5xx 响应的区分很粗糙，比如
503 Service Unavailable适合重试，但409 Conflict往往说明业务冲突，不该重试
怎么安全地加重试 + 幂等头
核心是把「构造请求」和「执行请求」拆开，确保每次重试都带唯一幂等标识，且请求体可复用：
- 用闭包或结构体封装原始参数，每次重试前调用
bytes.NewReader()或strings.NewReader()重建Body - 生成一次
Idempotency-Key（推荐uuid.NewString()），在首次请求时写入 Header，并在所有重试中复用——不能每次重试都生成新 key - 只对明确可重试的状态码重试：
502、503、504、0（网络错误）；跳过4xx（除429外） - 用
time.AfterFunc或backoff库做退避，别用固定间隔——避免雪崩
示例片段：
立即学习“go语言免费学习笔记（深入）”；
req, _ := http.NewRequest("POST", "https://api.example.com/pay", strings.NewReader(`{"amount":100}`))
req.Header.Set("Idempotency-Key", uuid.NewString()) // ← 只设一次
req.Header.Set("Content-Type", "application/json")
// 重试逻辑里：
for i := 0; i < maxRetries; i++ {
// 必须重建 Body，否则第二次是空
req.Body = io.NopCloser(strings.NewReader(`{"amount":100}`))
resp, err := client.Do(req)
if err == nil && (resp.StatusCode >= 500 || resp.StatusCode == 502 || resp.StatusCode == 503 || resp.StatusCode == 504) {
time.Sleep(backoff(i))
continue
}
return resp, err
}
服务端没实现幂等怎么办
如果调用的是第三方 API，且文档没提 Idempotency-Key 支持，那就得换策略：
- 先查再操作：比如调用支付前，先用订单号查
GET /orders/{id}，确认未支付再发POST /pay - 用本地状态兜底：在 DB 记录「请求发起时间 + 请求摘要（如 payload hash）+ 状态」，重试前先查这条记录是否已存在且完成
- 接受最终一致性：对某些场景（如日志上报），允许重复但由下游去重，这时幂等逻辑移到消费者端，而非 HTTP 层
注意：SELECT ... FOR UPDATE 或 INSERT ... ON CONFLICT DO NOTHING 是常见防重手段，但别依赖单条 SQL 原子性覆盖所有并发路径——网络分区下仍可能漏判。
容易被忽略的边界：Context 和 Cancel
重试逻辑里 context.Context 不只是传超时，更是取消信号源：
- 整个重试流程应共用一个
ctx，任意一次Do()都要传进去，否则单次请求超时了，重试还在继续 - 别在重试循环里新建
context.WithTimeout()，会导致上层 cancel 失效 - 如果重试期间用户主动取消（比如 HTTP 请求被前端 abort），要立刻退出，而不是硬扛完所有次数
真正麻烦的不是重试本身，而是「什么时候该停」——超时、错误类型、服务端返回的 Retry-After header、客户端资源限制（比如 goroutine 数量），这些信号得同时参与决策，没法靠一个 for 循环解决。
