Go重试需闭环四要素：判断可重试错误（如超时、503/504）、指数退避加抖动、保障幂等（如idempotency key、ON CONFLICT）、用context管控生命周期。
Go 语言中处理重试逻辑，核心在于三件事：判断是否可重试、控制重试节奏（退避）、确保操作幂等。这三者缺一不可，否则容易陷入无限重试、服务雪崩或数据重复写入。
哪些错误值得重试？
不是所有错误都该重试。网络超时、临时连接拒绝（如 net.OpError）、HTTP 503/504、数据库连接中断等属于“临时性失败”，适合重试；而 400、401、404 或结构体字段校验失败这类语义错误，重试无意义，应直接返回。
- 用
errors.Is(err, context.DeadlineExceeded)或errors.Is(err, syscall.ECONNREFUSED)判断底层临时错误 - 对 HTTP 客户端，检查
resp.StatusCode是否在[500, 599]区间（排除 501/505 等明确不支持的） - 封装一个
IsRetryable(err error) bool函数，集中管理重试策略，避免散落各处
指数退避（Exponential Backoff）怎么实现？
简单 for 循环 + time.Sleep 容易写成固定间隔，压垮下游。推荐用指数退避：每次等待时间翻倍，并加入抖动（jitter）防并发重试风暴。
- 基础公式：
wait = min(base * 2^attempt, maxDelay) - 加抖动：在 wait 上叠加随机偏移（如 ±25%），用
rand.Float64()*0.5 - 0.25 - Go 标准库没内置退避，但可用
golang.org/x/time/rate做限流辅助，或直接手写（几行即可） - 示例节选：
delay := time.Duration(math.Pow(2, float64(attempt))) * time.Second<br>delay = time.Duration(float64(delay) * (0.75 + rand.Float64()*0.5))<br>delay = clamp(delay, 100*time.Millisecond, 30*time.Second)<br>time.Sleep(delay)
为什么幂等是重试的前提？
重试会让同一请求发多次。如果下游没有幂等保障（比如“创建订单”接口没带唯一 ID），就可能生成多笔重复订单。Go 层能做的，是提供幂等标识并配合下游约定。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
立即学习“go语言免费学习笔记（深入）”；
- 对外部 API 调用，带上客户端生成的
X-Idempotency-Key（如 UUIDv4），由服务端校验去重 - 本地数据库操作，用
INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）或REPLACE INTO/INSERT IGNORE（MySQL） - 涉及状态变更的业务逻辑，先查后改（select-for-update + 条件更新），或用状态机约束（如只允许从 “pending” → “success”）
用标准库 context 控制整体生命周期
重试不能无限跑下去。用 context.WithTimeout 或 context.WithDeadline 统一约束整个重试过程，比手动计数更可靠。
- 每次重试前检查
ctx.Err() != nil，及时退出 - 把 context 传给底层调用（HTTP client、DB query），让它们也能响应取消
- 避免在重试循环里新建 context（如反复
context.WithTimeout），应复用最外层 context
基本上就这些。重试不是加个 for 循环那么简单，关键在“可重试判断 + 退避节奏 + 幂等保障 + 上下文管控”四者闭环。写得清楚，线上就少半夜告警。
