Go 中超时控制唯一可靠入口是 context.WithTimeout 或 context.WithDeadline，必须透传至 HTTP/gRPC/DB 等底层调用，禁用手动计时器或内部新建 context。
Go 的 context.WithTimeout 是超时控制的唯一可靠入口
微服务调用中，不设超时等于放弃稳定性。Go 原生只应通过 context.WithTimeout 或 context.WithDeadline 注入超时信号，其他方式（如手动计时器 + select）无法穿透 HTTP 客户端、gRPC 连接、数据库驱动等底层封装。
关键点在于：超时必须从上层 context 一路透传到底层调用链。例如发起 HTTP 请求时，需把带超时的 ctx 传给 http.NewRequestWithContext；gRPC 调用则必须用 grpc.DialContext 和每个方法的 ctx 参数。
- 不要在函数内部新建
context.Background()后再套WithTimeout—— 这会切断父级取消信号 - HTTP 客户端默认不读取 context 超时，必须显式使用
http.NewRequestWithContext，否则client.Timeout仅作用于连接建立阶段，不覆盖请求体发送或响应读取 - gRPC 的
ctx超时优先级高于DialOptions中的KeepaliveParams，但不会中断已发出的流式响应，只影响后续新请求
重试不能靠裸循环，必须配合 context 和错误分类
无条件重试会放大雪崩风险，尤其面对 503、gRPC Unavailable 或网络闪断时。真正的重试逻辑必须满足三个前提：当前 context 尚未超时、错误属于可重试类型、重试次数未达上限。
典型误用是写 for i := 0; i —— 这完全忽略 context 取消，且 sleep 时间固定，可能在最后一次重试刚启动时 context 已过期。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 每次重试前先
select { case ，确保没被上游取消 - 只对临时性错误重试：
net.OpError、context.DeadlineExceeded（注意：这是上一次调用的失败结果，不是当前 ctx 状态）、gRPC 的codes.Unavailable/codes.ResourceExhausted - 避免对
codes.InvalidArgument、codes.NotFound或 JSON 解析失败这类客户端错误重试 - 推荐用指数退避：
time.Sleep(time.Millisecond * time.Duration(math.Pow(2, float64(attempt))) * 100)，但首次 delay 至少 10ms，防止毛刺请求打满下游
HTTP 客户端超时字段和 context 的分工必须厘清
http.Client 有 Timeout、Transport 下的 IdleConnTimeout、TLSHandshakeTimeout 等多个超时配置，但它们和 context 不是互斥关系，而是分层协作：
-
client.Timeout是整个请求生命周期上限（从RoundTrip开始到结束），但它**不感知 context 取消**；一旦设置，即使 context 已取消，该 timeout 仍会强制终止请求 -
context.WithTimeout控制的是「你愿意等多久」，它能提前中断阻塞中的 DNS 查询、TCP 连接、TLS 握手、请求写入、响应读取等任意环节 - 最佳实践是：设一个宽松的
client.Timeout（如 30s）作为兜底，再用更精细的context.WithTimeout（如 2s）控制业务侧等待时间 - 若两者冲突（如 context 1s 超时，client.Timeout=30s），以更早触发者为准；但若 context 先取消，
RoundTrip会返回context.Canceled，而非client.Timeout错误
gRPC 调用中 context 超时对流式 RPC 的影响容易被低估
Unary RPC 的超时行为直观：context 过期 → 请求终止 → 返回 context.DeadlineExceeded。但流式 RPC（如 ClientStream）不同：超时 context 只会影响 Send 和 Recv 的**下一次调用**，已建立的流不会被主动关闭，也不会触发服务器端自动 cleanup。
- 若在
stream.Recv()阻塞时 context 超时，会立即返回 error，但 stream 对象本身仍有效——后续再调用Recv()会报io.EOF或transport is closing - 服务器端不会因 client context 超时而自动 cancel 流处理逻辑，必须手动监听
ctx.Done()并退出 for-loop - 流式重试比 unary 更复杂：需重建 stream，且要处理服务端可能已部分响应的情况，建议只在明确支持幂等的场景下启用（如带唯一 request_id 的事件推送）
- 调试时注意：
grpc.WithBlock()会让DialContext等待连接就绪，此时 context 超时会直接失败；生产环境应禁用该选项，改用连接健康检查
实际线上服务里，最常被忽略的是 context 的跨 goroutine 传递完整性——比如在 handler 中启了一个子 goroutine 处理异步回调，却忘了把原始 ctx 传进去，导致超时信号丢失。这比选错重试策略更容易引发连锁超时。
