context.WithTimeout无法跨HTTP边界传递，必须通过请求头（如X-Request-Timeout）编码超时语义，下游解析后创建新context；HTTP客户端需配置Transport全链路超时，gRPC应禁用WaitForReady并配合grpc.Timeout，服务端须及时响应ctx.Err()。
context.WithTimeout 不能直接跨 HTTP 边界传递超时
go 的 context.withtimeout 创建的 context 只在当前进程内有效，http 请求发出去后，下游服务根本收不到你的 ctx.deadline。你设了 5 秒超时，但下游可能用默认 30 秒，或者压根没读取超时头——链路就断了。
真正能跨服务传递的是「语义」，不是 context 对象本身。必须把超时意图编码进请求头（比如 X-Request-Timeout 或标准的 Grpc-Timeout），再由下游主动解析并据此创建自己的 context.WithTimeout。
- 上游：写入请求头，如
req.Header.Set("X-Request-Timeout", "4500")（毫秒） - 下游：解析该头，转换为
time.Duration，再调用context.WithTimeout(parentCtx, timeout) - 注意单位一致性：Go 的
time.Millisecond是 int64，别用 float 或秒级字符串直接 parse
HTTP 客户端侧必须显式设置 Transport 超时，否则 context 超时不生效
http.Client 默认没有底层连接/读写超时，仅靠 context.WithTimeout 只能中断阻塞的 goroutine，但 TCP 连接可能卡在 SYN、TLS 握手或服务器未响应阶段，导致实际耗时远超预期。
必须配全 http.Transport 的三类超时，并确保它们 ≤ 上游传来的逻辑超时值：
-
Transport.DialContext：控制建连（含 DNS 解析），建议 ≤ 总超时的 1/3 -
Transport.TLSHandshakeTimeout：TLS 握手，通常 5–10s 足够 -
Transport.ResponseHeaderTimeout：从发完请求到收到 header 的时间，应 ≤ 剩余超时
示例：
timeout := 5 * time.Second
client := &http.Client{
Transport: &http.Transport{
DialContext: func(ctx context.Context, network, addr string) (net.Conn, error) {
return (&net.Dialer{
Timeout: timeout / 3,
KeepAlive: 30 * time.Second,
}).DialContext(ctx, network, addr)
},
TLSHandshakeTimeout: 5 * time.Second,
ResponseHeaderTimeout: timeout - timeout/3 - 2*time.Second,
},
}
gRPC 场景下优先用 grpc.WaitForReady(false) + grpc.Timeout，而非依赖 context
gRPC Go 客户端对 context 超时的支持较完善，但要注意：默认行为是 WaitForReady=true，即超时前会不断重试失败连接，这会让实际耗时突破 context deadline。生产环境必须显式关掉。
- 正确做法：
ctx, cancel := context.WithTimeout(parentCtx, 3*time.Second)+grpc.WaitForReady(false)+grpc.Timeout(3*time.Second) -
grpc.Timeout是 gRPC 自己的传输层超时，比纯 context 更可靠；WaitForReady(false)防止 retry 拖垮 deadline - 服务端也要在 handler 中检查
ctx.Err()，及时 return，不能只依赖 stream.CloseSend
超时传递必须做「减法」，不能原样透传
上游设了 5s，下游处理用了 800ms，留给下游的下游只剩 4.2s。如果每个服务都忽略已消耗时间，链路末端可能累积出严重偏差，甚至出现「上游已超时，下游还在跑」的情况。
推荐做法是：上游记录发起时间（start := time.Now()），计算剩余时间：
remaining := timeout - time.Since(start)
if remaining <= 0 {
// 立即返回 408 或取消请求
}
req.Header.Set("X-Request-Timeout", strconv.FormatInt(int64(remaining.Milliseconds()), 10))
这个逻辑要封装进统一的 client middleware，避免每个 HTTP 调用都手动算。gRPC 同理，需在 interceptor 中动态调整 grpc.Timeout 值。
最容易被忽略的一点：中间件里的时间计算必须用 time.Now()，不能复用 handler 入口的 ctx.Deadline() —— 因为 deadline 是绝对时间点，而网络延迟、调度延迟会让不同服务看到的「已过时间」不一致。
