go中context.withtimeout不能自动跨http边界传播，因为context是进程内内存结构，http协议不携带其元数据；必须显式通过请求头（如x-request-timeout）传递剩余超时时间，并在服务端解析后调用context.withtimeout构造新context。
Go 中 context.WithTimeout 为什么不能自动跨 HTTP 边界传播
因为 context.Context 是内存内的、进程级的控制结构，HTTP 请求本身不携带 context 元数据。服务 A 调用服务 B 时，A 的 ctx 超时时间不会自动变成 B 的处理时限——B 根本不知道 A 设了 3s 还是 30s。
必须显式把超时信息编码进请求头（如 X-Request-Timeout 或更标准的 Grpc-Timeout），再由 B 主动解析并构造新 context。否则 B 可能跑满自身默认 timeout（比如 30s），导致 A 已超时放弃，B 却还在干耗资源。
- HTTP 客户端发请求前，需从当前
ctx提取剩余超时时间（ctx.Deadline()），转成秒级字符串写入ctx的 header map - HTTP 服务端收到请求后，读取该 header，调用
context.WithTimeout(parentCtx, timeout)构造子 context 用于后续 handler - 注意：如果原始 context 没 deadline（如
context.Background()），header 应为空或跳过设置，避免误设 0s timeout
如何用 net/http + context 正确传递和消费超时头
Go 标准库不自动处理超时头，得自己封装。关键在两处：客户端加头、服务端解析并重置 context。
客户端示例（带剩余时间计算）：
func doRequest(ctx context.Context, url string) (*http.Response, error) {
// 计算剩余超时
if d, ok := ctx.Deadline(); ok {
remaining := time.Until(d)
if remaining > 0 {
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
req.Header.Set("X-Request-Timeout", strconv.FormatInt(int64(remaining/time.Millisecond), 10))
return http.DefaultClient.Do(req)
}
}
return http.DefaultClient.Do(http.RequestWithContext(ctx, "GET", url, nil))
}
服务端中间件示例（提取并覆盖 request context）：
func timeoutPropagationMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if timeoutMs := r.Header.Get("X-Request-Timeout"); timeoutMs != "" {
if ms, err := strconv.ParseInt(timeoutMs, 10, 64); err == nil && ms > 0 {
timeout := time.Duration(ms) * time.Millisecond
ctx, cancel := context.WithTimeout(r.Context(), timeout)
defer cancel()
r = r.WithContext(ctx)
}
}
next.ServeHTTP(w, r)
})
}
- header 值建议用毫秒整数（而非 RFC 7231 的 duration 字符串），避免解析歧义
- 服务端一定要用
r.WithContext()替换原 request，否则 handler 拿到的仍是旧 context - 别在中间件里直接用
context.WithTimeout(r.Context(), ...)后不 cancel——必须配对defer cancel()
gRPC 场景下更省事：用 grpc.WithTimeout 和 grpc.TimeoutHeader
gRPC 协议原生支持超时传播，靠 grpc.Timeout metadata key（即 grpc-timeout header）。只要客户端用 grpc.WithTimeout，服务端默认就识别并应用。
客户端无需手动设 header：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() resp, err := client.SomeMethod(ctx, req)
服务端也无需额外中间件——gRPC Server 默认会从 grpc-timeout 解析并设置 handler context 的 deadline。
- 但注意：gRPC 的 timeout 是「从发送请求开始计」，不是从服务端接收开始；若网络延迟大，服务端实际可用时间会缩短
- 如果服务端想覆盖或校验该 timeout（比如强制不低于 100ms），仍需手动读
metadata.MD中的grpc-timeout字段 - gRPC 的 timeout header 值格式是
100m（100 毫秒）、5S（5 秒），大小写敏感，单位必须是m/S/s/M/H
容易被忽略的边界情况和坑
超时传播不是设个 header 就完事，真实链路里几个点常被漏掉：
- 中间代理（如 Envoy、Nginx）可能吞掉或改写自定义 timeout header，需确认其透传策略；gRPC 的
grpc-timeout通常被代理保留，但X-Request-Timeout很可能被过滤 - 服务 B 调用服务 C 时，应继续向下传播——不能只做“入口解包”，而要形成完整链路；建议统一封装一个
PropagatedContext工具函数，在每次 outbound 请求前注入 - 当 context 因超时取消时，
ctx.Err()是context.DeadlineExceeded，但下游服务返回的 HTTP 状态码仍是 200（除非你主动拦截并返回 408/504）；监控和日志里得同时查 header 和ctx.Err()才能归因 - 长轮询或流式接口（HTTP streaming / gRPC streaming）中，初始 timeout 仅约束建立连接阶段，后续数据帧不继承；需要单独为 stream 生命周期设计心跳或续期机制
最麻烦的从来不是怎么传，而是传过去之后，每个环节是否真正在用它做取消判断——比如数据库查询、文件读写、第三方 SDK 调用，都得明确接受 context 参数并响应取消信号。
