Go中服务调用超时管理需以context.Context为核心，HTTP调用通过WithContext()注入超时ctx并禁用client.Timeout，gRPC直接传入独立超时ctx，同时做好超时日志、指标上报与连接清理。
在 Go 中实现服务间调用的超时管理，核心是利用 context.Context 控制请求生命周期，配合 HTTP 客户端或 gRPC 客户端的超时机制，避免单个慢请求拖垮整个服务。
HTTP 服务调用：用 context.WithTimeout 包裹请求
Go 的 http.Client 本身不自动感知 context 取消，但可通过 req.WithContext() 将 context 传递给请求，使底层连接、DNS 解析、TLS 握手和读写过程都能响应取消信号。
- 创建带超时的 context：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) - 将 context 注入 request：
req = req.WithContext(ctx) - 务必调用
cancel()（建议 defer）防止 context 泄漏 - 检查响应错误是否为
context.DeadlineExceeded或context.Canceled，区分超时与业务错误
gRPC 调用：直接传入 context 并设置超时选项
gRPC 的 Go SDK 原生支持 context，调用方法时直接传入即可。推荐在每次 RPC 调用前创建独立的超时 context，而非复用长生命周期 context。
- 示例：
ctx, cancel := context.WithTimeout(ctx, 2500*time.Millisecond) - 调用时传入：
client.GetUser(ctx, &pb.GetUserRequest{Id: "123"}) - 服务端也可通过
ctx.Deadline()获取剩余时间，动态调整处理逻辑（如降级、跳过非关键步骤） - 注意：gRPC 默认启用 keepalive，若服务端长时间无响应，需结合
WithBlock()和重试策略谨慎使用
客户端级别超时：避免“超时嵌套”陷阱
不要同时设置 http.Client.Timeout 和 context 超时——二者行为不同且可能冲突。优先使用 context 控制，禁用 client 级别 timeout：
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：
client := &http.Client{Timeout: 0}（禁用内置 timeout） - 错误做法：既设
client.Timeout = 5s，又用context.WithTimeout(..., 3s)，导致实际超时不可控 - 若需连接/握手阶段硬限制，可用
http.Transport的DialContext+ 自定义 timeout，但应短于业务超时
超时后清理与可观测性
超时不是终点，而是故障处理的起点。需记录日志、上报指标，并考虑下游影响：
- 记录结构化日志，包含目标服务名、path、超时阈值、实际耗时、traceID
- 上报 Prometheus 指标如
rpc_client_request_duration_seconds{service="user", result="timeout"} - 对关键链路，可配置熔断器（如
sony/gobreaker），连续超时后快速失败，避免雪崩 - 避免在超时后继续处理响应体（如
resp.Body.Close()必须执行，否则连接无法复用）
