超时必须用 context.withtimeout 且透传到底层调用，http 要用 withcontext、grpc 用 dialcontext 和方法级 ctx、db 用 querycontext 等，禁用 background + withtimeout 和手动 for 重试。
超时必须用 context.WithTimeout，且要透传到底层调用
Go 中唯一可靠、可穿透的超时控制入口只有 context.WithTimeout 或 context.WithDeadline。其他方式——比如在业务层起 goroutine + time.After + select，或只靠 http.Client.Timeout——都无法真正中断底层 I/O 操作。
常见错误现象：HTTP 请求卡住 10 秒才返回 context.DeadlineExceeded，但实际连接早已建立、请求体已发出、响应头也收到了，只是响应体读取慢；或者数据库查询没响应，client.Timeout 根本不生效。
-
http.Client.Timeout只控制整个RoundTrip生命周期，但它不感知 context 取消；即使 ctx 已超时，它仍会等到自身 timeout 触发才结束 - 发起 HTTP 请求必须用
http.NewRequestWithContext(ctx, ...)，不能只创建普通*http.Request再传给client.Do() - gRPC 调用必须用
grpc.DialContext和每个方法的ctx参数，否则超时信号进不去底层连接 - 数据库操作必须用
QueryContext、ExecContext等带Context的方法，原生Query/Exec完全无视超时 - 禁止在函数内部写
ctx := context.Background(); ctx = context.WithTimeout(...)—— 这切断了上游 cancel 信号，变成“假超时”
重试不能写 for 循环，得用 RoundTripper 或 backoff.Retry
在业务函数里手写 for i := 0; i 是最常见也最危险的重试写法。它把错误分类、退避、上下文取消、goroutine 泄漏等全耦合在一起，一改就崩。
正确做法是分层拦截：HTTP 用自定义 RoundTripper，gRPC 用拦截器，通用逻辑用 backoff.Retry（来自 github.com/cenkalti/backoff/v4）。
- HTTP 重试只对
net.OpError、url.Error的Timeout()返回 true、或响应码为502/503/504时触发；400、404、401绝对不重试 - 别复用
http.DefaultClient并全局加重试逻辑——健康检查、metrics 接口也会被重试，反而放大下游压力 - 每次重试前必须新建子 context：
ctx, cancel := context.WithTimeout(parentCtx, timeout)，绝不能复用已 cancel 的 ctx - gRPC 重试需同时满足三条件：
grpc.WithChainUnaryInterceptor(grpc_retry.UnaryClientInterceptor())、grpc.WithDefaultServiceConfig注入 JSON 策略、grpc_retry.WithCodes(codes.Unavailable, codes.ResourceExhausted) - proto.Message 必须可重复序列化；含
sync.Mutex或闭包字段会导致重试 panic
超时与重试的协作边界必须厘清
很多人以为设置了 http.Client.Timeout 就不用 context，或以为开了 gRPC 重试就自动带超时——这两者既不互斥，也不替代，而是分层协作关系。
典型误配：gRPC 客户端配置了重试策略，但没传带超时的 ctx，结果重试三次全卡在第一次请求的阻塞上；或 HTTP client 设置了 Timeout: 5s，但 request 没传 context，导致 DNS 解析失败时等满 5 秒才报错，而其实 ctx 早在 1 秒后就该取消。
-
http.Transport.DialContext的Timeout控制 TCP 连接建立，应设为 1–3 秒；ResponseHeaderTimeout控制响应头到达时间，建议 2–5 秒；client.Timeout是兜底总时限，通常设为 10–30 秒 - context 超时应比 client 总 timeout 更短，比如 client 设 10s，context 设 8s——留出 2s 给 client 自身开销和错误包装
- gRPC 的
ctx超时优先级高于KeepaliveParams，但不会中断已发出的流式响应，只影响后续新请求 - 重试中的每次请求都应有独立超时：第一次用 8s，第二次用 6s，第三次用 4s（按剩余 SLA 动态计算），而不是三次都用同一个固定 timeout
容易被忽略的幂等性与状态泄漏
重试本身不危险，危险的是重试后状态不一致。这不是 Go 语言问题，而是服务契约问题——但 Go 开发者最容易在这里掉坑。
例如：支付接口被重试三次，下游没做幂等，结果扣了三笔钱；或用户注册接口重试，生成了三个重复账号。这类问题在日志里只显示 “重试成功”，根本看不出异常。
- 所有对外 RPC/HTTP 调用，必须确认对方是否支持幂等（如通过
Idempotency-Keyheader 或请求 body 中的唯一 trace_id） - 本地重试逻辑不能假设“只要没报错就是成功”——要检查响应 body 中的业务 code，比如
{"code": 200, "msg": "success"}才算真成功，{"code": 500, "msg": "already exists"}可能意味着幂等生效，但不算失败 - goroutine 泄漏高发场景：重试循环里忘了
defer cancel()，或select没监听ctx.Done()导致 channel 阻塞 - 熔断器（如
sony/gobreaker）和重试不是一回事：重试解决瞬时抖动，熔断解决持续不可用；两者要分开配置、分别监控，不能用重试次数代替失败率统计
