context.withtimeout不能直接传time.now().add()，因其内部需基于当前时间计算截止时刻，手动计算易因时钟漂移、纳秒误差或goroutine间时间不一致导致提前取消，且若传入过去时间点会立即触发done并返回context.deadlineexceeded错误。
context.WithTimeout 为什么不能直接传 time.Now().Add()？
因为 context.WithTimeout 内部会基于当前时间计算截止时刻，你传入的 time.Time 必须是未来时间点；如果手动算好再传，容易因系统时钟漂移、纳秒级误差或跨 goroutine 时间不一致导致提前取消。更关键的是：一旦传入过去的时间点，context 立即进入 Done 状态，<ctx>.Err()</ctx> 返回 context.DeadlineExceeded，但这个错误可能被静默吞掉。
正确做法永远用 context.WithTimeout(parent, timeout)，让 runtime 自己算：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel()
- 不要写
context.WithDeadline(ctx, time.Now().Add(5*time.Second)) - 超时值建议从配置读取，避免硬编码（如
viper.GetDuration("service.timeout")） - 若需动态调整超时（比如下游服务降级），应重新构造新
ctx，而非复用旧cancel
HTTP client 调用下游服务时，timeout 设置在哪一层生效？
Go 的 http.Client 本身有 Timeout 字段，但它只控制整个请求生命周期（DNS + 连接 + TLS + 发送 + 接收响应头），不包括响应体读取。而微服务间调用常涉及大 payload 或流式响应，这时候仅靠 Client.Timeout 不够。
必须把 context.Context 透传进 client.Do(req.WithContext(ctx))，否则 context 超时根本不会中断底层连接：
立即学习“go语言免费学习笔记（深入）”；
req, _ := http.NewRequestWithContext(ctx, "GET", "http://svc-b:8080/api", nil) resp, err := client.Do(req)
-
http.Client.Timeout和context超时要配合使用，前者兜底防卡死，后者支持细粒度中断 - 若用
resty或gorest等封装库，确认其SetContext()是否真正透传到底层http.Request - Kubernetes 中
Service的externalTrafficPolicy: Local可能导致连接 hang 住，此时context超时是唯一可靠退出方式
gRPC 客户端调用如何正确传递 context 超时？
gRPC 的 context 是一等公民，所有 RPC 方法第一个参数都必须是 context.Context。但常见错误是：只在发起调用时传了 ctx，却忘了在 server 端检查 ctx.Err() 并及时 return，导致 server 继续执行无意义逻辑。
客户端侧只需确保 ctx 带超时并传入：
ctx, cancel := context.WithTimeout(ctx, 3*time.Second)
defer cancel()
resp, err := client.GetUser(ctx, &pb.GetUserRequest{Id: "123"})
- 服务端必须在关键阻塞点（如 DB 查询、下游 HTTP 调用）前检查
if ctx.Err() != nil { return nil, ctx.Err() } - 不要在 server handler 里用
context.Background()新起 goroutine，那会脱离父ctx生命周期 - 若使用
grpc-go的拦截器（interceptor），注意UnaryServerInterceptor中的ctx已含 deadline，可直接复用
微服务链路中 context 超时被“吃掉”的典型场景
最隐蔽的问题不是超时不生效，而是超时发生了，但错误被掩盖：比如日志没打、监控没上报、fallback 逻辑误判为业务失败而非超时。
关键识别点是看 err 类型是否为 context.DeadlineExceeded 或 context.Canceled，而不是笼统判断 err != nil：
if errors.Is(err, context.DeadlineExceeded) {
metrics.TimeoutCounter.Inc()
return fallbackData, nil // 明确走降级
}
- 用
errors.Is(err, context.DeadlineExceeded)判断，别用err == context.DeadlineExceeded（类型不同） - 中间件或通用工具函数（如重试封装）可能把原始
ctx.Err()转成其他 error，需逐层 inspect - Jaeger/OTLP 链路追踪中，若 span 状态始终是
STATUS_OK，但耗时远超设定 timeout，说明超时未触发 cancel 或被 recover 吞掉了
ctx 的信号——从入口 HTTP/gRPC handler，到中间件、DB 查询、消息发送、甚至 defer 清理逻辑，只要有一处忽略 ctx.Done()，整条链路就可能卡死或资源泄漏。 
