gRPC客户端需用context.WithTimeout包裹请求上下文以设置超时，服务端须主动检查ctx.Err()并在阻塞操作中传递ctx；未调用cancel()会导致goroutine泄漏。
gRPC 客户端调用如何设置超时
gRPC 本身不直接提供超时参数，必须通过 context.WithTimeout 或 context.WithDeadline 包裹请求上下文。服务端是否响应、网络是否通畅、序列化是否卡住——这些都由 context 控制，一旦超时，客户端会立即取消请求并返回 context.DeadlineExceeded 错误。
常见错误是只在业务逻辑里加超时，却忘了传给 gRPC 方法：
- 错：直接用
context.Background()调用client.SayHello(ctx, req) - 对：先创建带超时的 ctx，再传入：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() resp, err := client.SayHello(ctx, req)
注意 cancel() 必须调用，否则可能泄漏 goroutine；如果后续还有其他操作（比如日志、fallback），建议用 defer cancel() 放在最前。
服务端如何感知并响应客户端超时
服务端收到的 ctx 是客户端传递过来的，自带 deadline 和取消信号。不能忽略它，也不能假设它“永远有效”。典型表现是：服务端函数执行到一半，ctx.Err() 突然变成 context.Canceled 或 context.DeadlineExceeded。
立即学习“go语言免费学习笔记（深入）”；
正确做法是在关键阻塞点主动检查：
- 数据库查询前：用
db.QueryContext(ctx, ...)替代db.Query(...) - HTTP 调用：传入
ctx到http.Client.Do(req.WithContext(ctx)) - 自定义 sleep 或轮询：用
select { case
别写死 time.Sleep(3 * time.Second) —— 这会无视所有超时控制，导致服务端继续跑完，浪费资源且拖慢整体链路。
Context 超时与 gRPC 流式调用的冲突点
流式 RPC（如 stream.Recv() / stream.Send()）容易出问题：一个长连接持续收发数据，但客户端设置的超时是针对整个 RPC 的起止时间，不是单次读写的间隔。
如果你需要“每次接收最多等 2 秒”，不能靠初始 context 超时解决，得手动包装：
- 对每个
Recv()单独套一层context.WithTimeout - 或改用
stream.Context().Done()配合time.AfterFunc做心跳检测 - 更稳妥的是服务端主动分块发送 + 客户端按需续租（例如每 10 条发一次 ack）
否则可能出现：客户端设了 5s 超时，但第 3 秒才收到第一条消息，后面每条间隔 1.5s —— 第四条就会因总耗时超限被断开，而你根本没机会处理中间状态。
Deadline 传播失效的常见原因
context 超时无法跨进程/跨语言生效，但即使同为 Go，也常因以下原因丢失 deadline：
- 用
context.WithValue从旧 ctx 提取值后，新建了一个纯context.Background()再塞回去 —— 新 ctx 没 deadline - 中间件或拦截器里忘了把入参
ctx透传下去，比如next(ctx, req)写成next(context.Background(), req) - 使用了某些封装库（如 grpc-gateway），默认把 gRPC ctx 转成 HTTP context，但没保留 deadline 字段
验证方法：在服务端入口打日志 log.Printf("deadline: %v, err: %v", ctx.Deadline(), ctx.Err())，看是否和客户端设置一致。不一致就说明 somewhere upstream 已经重置过 context。
