go微服务中context.withtimeout传递失败的典型表现是超时未传到下游，上游已取消但下游仍在运行，日志仅调用方报“context deadline exceeded”，被调用方无感知；根本原因是http/grpc透传时未正确使用标准机制（如grpc-timeout或x-timeout-ms），导致cancel信号断链。
Go微服务中context.WithTimeout传递失败的典型表现
超时没传到下游，上游已取消但下游还在跑，日志里看到 context deadline exceeded 只出现在调用方，被调用方压根没感知。这不是 context 没传，而是传了但没用对——常见于手动拼接 HTTP header、gRPC metadata 时漏掉了 deadline 和 cancel 信号。
- HTTP 调用：只传了
X-Request-ID却忘了透传Grpc-Encoding或自定义的X-Deadline（其实该用标准grpc-timeout） - gRPC 调用：用
ctx = metadata.AppendToOutgoingContext(ctx, ...)但没调用grpc.SendHeader()或忽略拦截器返回的 error - HTTP/JSON 场景：把
context.Deadline()算出秒数塞进 query 参数，但下游没解析，或时区/精度错乱（time.Now().Unix() vs time.Now().UnixNano()）
gRPC 全链路 timeout 必须走拦截器 + 标准 metadata
gRPC 官方协议本身支持超时透传，但前提是两端都启用拦截器，且使用标准 key：grpc-timeout。自己造 key 或靠业务层解析，等于绕过协议语义，context.CancelFunc 就断在第一跳。
- 客户端拦截器里必须调用
grpc.UseCompressor()以外的grpc.WithBlock()不相关，重点是确保ctx被正确注入到metadata.MD中，key 固定为grpc-timeout，value 格式为"100m"（单位只能是h/m/s/ms/us/ns） - 服务端拦截器需调用
grpc.SetHeader()或grpc.SendHeader()触发 deadline 解析；否则ctx.Err()一直为 nil，直到连接级超时（如 TCP keepalive）才断 - 注意 gRPC-Go v1.60+ 对
grpc-timeout的解析更严格：如果 value 含空格或单位非法，整个 metadata 被静默丢弃，下游 ctx 永远不会 cancel
HTTP 微服务间 context deadline 无法自动透传，必须手动转换
HTTP 没有内置 deadline 透传机制，context.WithTimeout 的 deadline 不会自动变成请求头。你得自己算、自己塞、下游自己读、自己转回 context——三步缺一不可，任一环节出错就断链。
- 上游：从
ctx.Deadline()算出剩余毫秒数，写入 header，推荐用X-Timeout-Ms（比自定义X-Deadline更直白，避免时区歧义） - 下游：收到后用
time.Now().Add(time.Duration(ms) * time.Millisecond)构造新ctx，别直接用context.WithTimeout(ctx, time.Duration(ms)*time.Millisecond)—— 这会覆盖原始 cancel channel，导致上游 cancel 信号丢失 - 关键陷阱：如果上游 deadline 已过（
ctx.Err() == context.DeadlineExceeded），下游不应再发起任何 IO，而应立即返回 408 或 503，否则形成“僵尸请求”
跨语言调用时 context.Cancel 不生效的根本原因
Go 的 context.CancelFunc 是内存级闭包，不可能跨进程或跨语言传递。所谓“全链路取消”，本质是各语言用自己的机制模拟 cancel 信号：gRPC 靠 grpc-timeout + RST_STREAM，HTTP 靠 connection close 或自定义 header + 主动 abort。指望 Go 的 context 直接让 Python 服务退出，是混淆了抽象与协议。
立即学习“go语言免费学习笔记（深入）”；
- Go 调 Python（requests）：必须在 Go 侧监听
ctx.Done()，一旦触发就调用req.Cancel()（需 requests >= 2.26）或关闭底层 connection - Python 调 Go：Python 侧需设置
timeout并捕获requests.Timeout，然后主动发终止信号（如 POST /_cancel）；Go 侧不能只等 HTTP 连接断开，要监听该 endpoint 并调用cancel() - 最易忽略的一点：即使所有链路都透传了 timeout，若某中间件（如 API 网关）未配置
read_timeout或send_timeout，它会缓冲请求并延迟转发 cancel，实际超时时间 = 网关 timeout + 后端 timeout
