因为HTTP/gRPC不自动透传context.Deadline，下游收不到超时语义，必须手动通过X-Request-Timeout等头传递剩余毫秒数并用context.WithDeadline重建ctx，gRPC还需显式注入grpc-timeout元数据并禁用WaitForReady。
Go 微服务中 context.WithTimeout 为什么传不到下游？
因为 HTTP 或 gRPC 默认不把 context.Deadline 自动转成请求头，下游收到的是一个空 context，超时时间彻底丢失。你调用 ctx, cancel := context.WithTimeout(parentCtx, 5*time.Second)，但下游服务启动自己的 30 秒默认超时，根本不会在 5 秒后取消。
HTTP 微服务必须手动透传 X-Request-Timeout 和 X-Request-Start
gRPC 有内置的 grpc.WaitForReady 和截止时间序列化机制，但 HTTP 没有标准头；主流做法是用两个自定义头约定：
-
X-Request-Timeout：传剩余毫秒数（不是绝对时间），比如4200 -
X-Request-Start：传发起请求时的 Unix 毫秒时间戳（用于下游校准偏移）
下游收到后，用当前时间减去 X-Request-Start，再用 X-Request-Timeout 减去这个差值，得到真实剩余超时，再调用 context.WithDeadline 构建新 ctx。别直接用 WithTimeout，否则会叠加误差。
gRPC 客户端必须启用 grpc.WaitForReady(false) 并设置 grpc.Timeout 元数据
gRPC 的 context 超时默认只作用于本机调用，不自动注入到 wire 上；要让服务端能读取，得显式塞进 metadata：
md := metadata.Pairs(
"grpc-timeout", "4.2s",
)
ctx = metadata.NewOutgoingContext(ctx, md)
注意：grpc-timeout 值必须是带单位的字符串（s、ms、us），且服务端需用 grpc.ServerOption 启用 grpc.MaxConnectionAge 不相关——真正关键的是服务端拦截器里调用 metadata.FromIncomingContext 解析它，并用 time.ParseDuration 转成 time.Duration 后调用 context.WithTimeout。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
另外，客户端必须设 grpc.WaitForReady(false)，否则超时前会一直重试，破坏链路控制语义。
中间件里别用 context.WithCancel 替代超时控制
有人图省事，在 HTTP 中间件里对每个请求起一个 context.WithCancel，然后开 goroutine 睡眠后调 cancel() —— 这看似实现了“超时”，但问题很大：
- 无法响应上游提前取消（比如用户关掉浏览器）
- goroutine 泄漏风险高（尤其高并发时）
- 和下游服务的超时行为不一致，链路断点不可控
正确路径永远是：解析上游 timeout → 计算本地 deadline → 用 context.WithDeadline 构造新 ctx → 全链路统一用该 ctx 发起子调用（HTTP/gRPC/DB）。deadline 是绝对时间点，比 duration 更可靠，尤其跨服务时钟漂移明显的情况下。
最容易被忽略的一点：所有 DB 查询、缓存操作、第三方 API 调用，都必须显式接收并使用这个透传来的 ctx；漏掉任意一个，整条链路的超时就失效了。
