Go HTTP客户端必须显式配置超时，推荐自定义http.Transport设置各阶段超时，并通过context.Context透传deadline，避免全局DefaultClient和硬编码dial选项，超时值需基于P99延迟分层设定并联动重试熔断。
Go HTTP client 默认不设超时，必须显式配置
Go 的 http.Client 默认没有超时限制，一旦后端卡住或网络异常，Do() 会无限等待。这不是 bug，是设计选择——但微服务场景下绝对不可接受。
正确做法是为每个 http.Client 实例设置 Timeout，或更精细地拆分为 Transport 级别的 DialContext、TLSHandshakeTimeout 等。生产环境推荐用后者，避免 DNS 解析、连接建立、TLS 握手等环节各自拖垮整体耗时。
-
Timeout是总超时（从发起请求到收到完整响应），覆盖重定向、重试，但无法控制单个连接阶段 - 若需区分连接超时与读写超时，应自定义
http.Transport，例如：tr := &http.Transport{ DialContext: (&net.Dialer{ Timeout: 5 * time.Second, KeepAlive: 30 * time.Second, }).DialContext, TLSHandshakeTimeout: 5 * time.Second, ResponseHeaderTimeout: 3 * time.Second, ExpectContinueTimeout: 1 * time.Second, } - 不要复用未设超时的全局
http.DefaultClient，尤其在高并发微服务中
context.WithTimeout 是跨层传递超时的唯一可靠方式
仅靠 http.Client.Timeout 不足以覆盖整个调用链：上游传来的 deadline、中间件处理耗时、下游服务再转发时的剩余时间，都得靠 context.Context 向下透传。
所有可取消操作（HTTP 调用、DB 查询、gRPC 调用、channel 操作）必须接收 context.Context 参数，并在内部调用 ctx.Done() 监听取消信号。
立即学习“go语言免费学习笔记（深入）”；
- 不要在 handler 中直接用
context.Background()构造新 context；始终用入参ctx衍生：childCtx, cancel := context.WithTimeout(ctx, 800*time.Millisecond) defer cancel() resp, err := client.Do(req.WithContext(childCtx))
- gRPC 客户端调用必须传 context：
client.GetUser(childCtx, req)，否则超时完全失效 - 注意
context.WithTimeout返回的cancel()必须调用，否则可能泄漏 goroutine（尤其在 error early return 场景）
gRPC 调用超时必须通过 context 控制，不能依赖客户端配置
gRPC Go SDK 的 grpc.Dial() 中的 grpc.WithTimeout 已被弃用，且实际不生效；真正起作用的是每次 RPC 调用时传入的 context.Context。
常见错误是以为设置了 dial 选项就一劳永逸，结果下游服务 hang 住时整个调用仍无响应。
- 每次
client.MethodName(ctx, req)都要确保ctx带有合理 deadline - 若上游已传入带 deadline 的 context，直接复用即可；若需缩短，用
context.WithTimeout(ctx, ...)衍生子 context - 不要在
grpc.Dial()里硬编码grpc.WithBlock()，它会阻塞直到连接建立成功，掩盖真实超时问题
超时值不是越小越好，需结合 P99 延迟和业务容忍度设定
盲目把所有超时设成 200ms 很危险：网络抖动、GC STW、慢盘 IO 都可能导致正常请求被误杀。真正的超时策略必须基于可观测数据。
建议分层设置：入口 API 层（如网关）设较宽松 timeout（比如 2s），内部服务间调用根据依赖链 P99 + buffer 设定（如依赖服务 P99 是 300ms，则调用方设 600ms）。
- 记录每次调用的实际耗时和是否因超时失败，用 Prometheus + Grafana 观察
http_client_request_duration_seconds_bucket分布 - 避免「所有服务统一设 500ms」这种拍脑袋配置；下游服务升级后延迟上升，上游却没同步调整 timeout，就会引发雪崩
- 对非关键路径（如日志上报、异步通知），可用
context.WithDeadline或time.AfterFunc做尽力而为调用，不阻塞主流程
超时控制的本质不是加一道保险，而是让系统在不确定中做出可预测的退让。最常被忽略的点是：超时必须和重试、熔断、降级联动，单独设 timeout 只是把失败从「卡死」变成「快速失败」，而没解决下游过载的根本问题。
